Input buffer overflow

[BrodieBruce901]

While using a bluetooth headset on ARM experimental branch I received this error:

03:00:59 WARN input.c:239: input buffer overflow!
Segmentation fault (core dumped)

It happens while using bluettooth audio. I can test the behavior on x86 as well if you would like.

[mrbubble62]

Also on ARM R8

chip@chip:~/nrsc5/build$ nrsc5 88500000 0
15:47:36 INFO main.c:178: [0] Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 1488375.071248 Hz
15:47:38 INFO main.c:65: Gain: 0.0 dB, CNR: 15.036225 dB
...
15:47:42 INFO main.c:65: Gain: 19.7 dB, CNR: 11.571646 dB
15:47:42 DEBUG main.c:69: Best gain: 14
15:47:46 DEBUG sync.c:244: First block @ 30
15:47:47 INFO sync.c:222: Synchronized!
15:47:49 WARN input.c:239: input buffer overflow!
Segmentation fault

[mrbubble62]

Fixed with
cmake -DUSE_THREADS=NO

[awesie]

If the input buffer is overflowing, then that means it couldn't process the data fast enough. Or, as might be the first case, it could mean that processing got stuck trying to output the audio.

By disabling threads, it eliminates the use of these intermediate buffers, so it is now impossible to have this issue.

The solution depends on the root cause. If it is because libao is hanging due to issues processing the audio, then the ideal solution is to drop audio samples. If it is because the machine isn't fast enough to do all of the processing, then the solution is likely dropping radio samples but this will cause desynchronization.

[awesie]

Let me know if you are still having buffer overflow issues after this commit. It should now properly drop audio buffers if for some reason libao is hanging.

[mrbubble62]

Thank you, build with threads gracefully handles overflow now.
Unfortunately ARM R8 platform is just not fast enough.

chip@chip:~/nrsc5/build$ nrsc5 -g 14 88500000 0
02:27:06 INFO main.c:178: [0] Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 1488375.071248 Hz
02:27:11 DEBUG sync.c:244: First block @ 1
02:27:13 DEBUG sync.c:244: First block @ 0
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:14 ERROR input.c:240: input buffer overflow!
02:27:15 ERROR input.c:240: input buffer overflow!
02:27:15 DEBUG sync.c:244: First block @ 0
02:27:15 ERROR input.c:240: input buffer overflow!
02:27:15 ERROR input.c:240: input buffer overflow!
02:27:15 INFO sync.c:222: Synchronized!
02:27:15 ERROR input.c:240: input buffer overflow!

[BrodieBruce901]

I've found the source of my issue. It is related to using a bluetooth headset and nrsc5 being unable to output the sound to it. Essentially if the bluetooth starts dropping or is about to disonnect, nrsc5 produces the error and it segmentation faults.

[BrodieBruce901]

I'm going to pull the new code and compile it now.

[BrodieBruce901]

The issue is resolved. The program gracefully returns audio back to on board sound if it can't send it to bluetooth. Thanks.