Popping when using default HRTF about steam-audio

[lakulish]

@Ravbug If the input samples are already close to +/- 1, then it's possible that the HRTF will cause the output samples to be slightly outside the [-1, 1] range, but based on the graph, that's not the issue here. Can you try creating the context with validation enabled (see here) and see if that indicates any invalid/NaN inputs?

[Ravbug]

I passed IPL_CONTEXTFLAGS_VALIDATION, and I didn't get any asserts or additional logs. The out-of-range values are in the ballpark of 10-20 so it doesn't seem like UB to me, but I could be wrong.

[lakulish]

Output sample values in the 10-20 range are definitely not expected. Do you happen to know what the source and listener positions were when these out-of-range sample values were generated? I want to make sure I'm able to reproduce the conditions under which you're encountering the issue. Thanks!

[Ravbug]

I reproduced it with these positions, in world space:
source pos: (0,0,0)
listener pos: (2.50609, 9.20201, 0)
listener rotation (quaternion xyzw): (-0.395396, 0.586227, 0.395396, 0.586227)

I noticed that the source audio (before SteamAudio sees it) has a couple of values in the [-20,20] range so this could partially be a case of garbage in -> garbage out, however, the buffers that SteamAudio produces have many more out-of-range samples than the input data. These samples also don't always align with the input out-of-range samples. Is this expected?

Here is another Desmos graph with the source buffer and resulting SteamAudio output buffers for this capture: https://www.desmos.com/calculator/14biausk1g

[achandak]

The all seems reasonable. Input seems to be in the range of [-30 to 20] and output from Steam Audio is in similar range. Samples don't align because HRTF is basically and FIR filter which adds delay and does a weights sum of various samples to generate output at a given sample.