Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buffering issue #10

Open
sp5wwp opened this issue May 13, 2021 · 4 comments
Open

Buffering issue #10

sp5wwp opened this issue May 13, 2021 · 4 comments

Comments

@sp5wwp
Copy link

sp5wwp commented May 13, 2021

"arecord ... | m17-mod ... > dump.raw" generates exactly 280ms of baseband, everytime.

@jketterl
Copy link
Contributor

jketterl commented May 13, 2021

from what i know: this is caused here since the 40ms timeout is too small when used with an actual audio device.

@jketterl
Copy link
Contributor

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.

@mobilinkd
Copy link
Owner

What do you expect to happen here?
Is GNU Radio reading from the named pipe when this is run?

@jketterl
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants