#2 Crash on custom delays over 9 s

[Nikolai Beier]

A segmentation fault can be provoked by entering 9 s (just the one digit”9” into the number field), then pressing “Custom” in the delay dialog. With 7 s it does not segfault, but often with 8 s.

Set custom delay to 3 s, and the Reference input level indicator will go all red constantly and the power density of the “Reference” shown in the graph rises about 40 dB.

Setting the delay to 2 s is not deterministic. some times the level indicator goes black, some times red (like observed with 3 s.).

It feels like there is a kind of undesired state machine in the code, or at least a bad interaction between the delay setting and the captured audio. Does the audio samples get changed before they are passed on to both the FFT library and the 4-color level indicators?

Under normal with sound reinforcement systems, delay values far below 1 s would be normal, given by the acoustic measurement distance below 300 m.

The delay gets inserted in the time domain before the FFT. Search the file BRP_PACU.c for “apply delay” around line 174.
The delay value is stored in the same struct (under “->delay_size”) as the audio samples (which end up in “->buffer_data_2[k])
The struct FFT_Frame declares: int delay_size;
When the delay is calculated (not “custom”) it seems the code can only set it to a value in the range [0 – 8191] (N_FFT=8192) due to the check in BRP_PACU.c line 250

For custom values entered in the gui, the float variable with the entered value in seconds, is multiplied with 44100 and the result cast to an “int”. If this results in a negative value (for 32 bit integer this happens between 2 and 3 s), an other code path is used to “apply a delay” (or wahtever actually happens).

Perhaps it goes wrong when the FFT_Frame->delay buffer is used in line 178?

Anyway, custom values can get trunkated/limited without the user can see it or is reminded of it, bu tthat is a separate bug.