Buffering issue
Opened this issue · 4 comments
"arecord ... | m17-mod ... > dump.raw" generates exactly 280ms of baseband, everytime.
from what i know: this is caused here since the 40ms timeout is too small when used with an actual audio device.
the link i posted above is no longer valid since the code has shifted. Here's a new one against the v2.0 tag: https://github.com/mobilinkd/m17-cxx-demod/blob/v2.0/apps/m17-mod.cpp#L504
I just tried m17-mod again, and this time the behavior was different... the output stopped after about 2 seconds, and m17-demod locked up. The stack revealed no frames inside the actual m17-mod code, so my suspicion is that it's the join() in the end, I haven't done any more testing on this.
Increasing the timeout to 2000 once again made the modulator work as expected.
Command-line in use:
arecord -t raw -f S16_LE -r 8000 -c 1 - | m17-mod --src DD5JFK > /tmp/m17-fifo
with m17-fifo being a fifo that is then fed into a GRC graph to perform FM modulation and transmit the result over a HackRF.
What do you expect to happen here?
Is GNU Radio reading from the named pipe when this is run?
Yes, GNU Radio is reading the audio data on the fifo though a file source block. This is just my little solution to be able to transmit M17 right now, and I'm using arecord as the input in order to use actual audio from my microphone.
I suspect that when compared with being fed from a file, arecord takes some more time to produce the initial data. When reading from a file, the whole pipeline would probably backbuffer since the output is read at a slower rate and will eventually block. When reading from a soundcard, the input and output rates of the setup should ideally be matched, so the process will probably oscillate between blocking on the input and blocking on the output.