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.

Sign up for GitHub

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

Jump to bottom

Issue with buffer size #1

Open
N5BRG opened this issue Sep 4, 2023 · 5 comments
Open

Issue with buffer size #1

N5BRG opened this issue Sep 4, 2023 · 5 comments
Assignees
@fventuri

Comments

@N5BRG
Copy link

N5BRG commented Sep 4, 2023

I install gr-rtp on RPi3 and on an I5 system and have it working with KA9Q radiod
using a RTLSDR receiver. However when I first strat the gnuradio application I get a good copy for a short time and then message that says:
rtp_source ⚠️ work buffer not large enough - dropping samples. Buffer size=180 Available samples=480. Buffer size=297 is coming up also. Alternating back and forth between 180 and 297.

I feel the issue is with the gnuradio radio oot buffers because I can stop it and restart while radiod runs in the background. I get good clean copy for a short time then warnings and the audio on the speaker is no longer clear but present. Audio is distorted.

I have looked through the code but not seeing a place to expand Buffer size?
@N5BRG
Copy link
Author

N5BRG commented Sep 4, 2023

I just pull most current code down. I changed the example sample rate to 2400 and I am not seeing Buffer issue. This is output I see and radio may be OK needs more testing.

Press Enter to quit: rtp_source :info: New session from 10@192.168.7.211:54406, type 117, channels 2, samprate 24000
aU

The aU looks like it may be a problem in print statement.

@fventuri
Copy link
Owner

fventuri commented Sep 4, 2023

Thanks for trying out this GNU Radio module with ka9q-radio.

This morning after reading your message I added the following line right after line 138 in 'lib/source_impl.cc':

    this->d_logger->info("noutput_items={} noutput_channels={} sampcount={} framecount={}", noutput_items, output_items.size(), sampcount, framecount);

After rebuilding the module, I let it run for a couple of minutes here, and it looks like in my case 'noutput_items' is always much bigger than 'sampcount' or 'framecount':

rtp_source :info: noutput_items=8192 noutput_channels=1 sampcount=240 framecount=240

which is probably why I don't see those "work buffer not large enough" warnings; if you add the same log message, you might be able to see if GNU Radio for some reason shrinks down the work buffer after a while.

I did some research, and found out that GNU Radio allows to set a minimum for the number of output items for a block via the method set_min_noutput_items() (https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8), so I would suggest to try adding a line like this at the end of the constructor for the source block (i.e. right after this line: https://github.com/fventuri/gr-rtp/blob/main/lib/source_impl.cc#L49):

    this->set_min_noutput_items(1440);

With a value like 1,440 the gr-rtp' source block should have enough room for the samples received in one UDP packet (240 in my case, 480 in yours) plus a couple of dropped packets (which 'gr-rtp' fills with zeroes, similar to what 'pcmcat' does in ka9q-radio).

The letters 'aU' are a specific code for 'audio underrrun' (see GNU Radio FAQ here: https://wiki.gnuradio.org/index.php/FAQ#I_have_a_receiver_with_an_audio_sink,_and_keep_getting_aUaUaU_errors?) - it basically means that the GNU Radio source (the 'gr-rtp' source block in this case) is generating samples at a slower rate than expected by the GNU Radio sink (the audio device). You may want to add a 'Probe rate' block (see this example: https://wiki.gnuradio.org/index.php/Probe_Rate - only the 'probe rate' block and the 'message debug' block are needed) right after the source block to see what the actual input sample rate is.

73,
Franco K4VZ

@fventuri fventuri self-assigned this Sep 4, 2023
@N5BRG
Copy link
Author

N5BRG commented Sep 4, 2023 via email

@N5BRG
Copy link
Author

N5BRG commented Sep 5, 2023 via email

@fventuri
Copy link
Owner

fventuri commented Sep 5, 2023

Thanks for your tests Bob.

The number of channels depends on what you have in the 'mode' line in the configuration file 'radiod@rtlsdr.conf' (assuming your configuration is similar to Tom's):

  • if you have mode = fm, the PCM stream will have only one channel (demodulated FM audio), and you should use the GNU Radio flowgraph called rtp_source_nws_fm.grc
  • if you have mode = iq, the PCM stream will have two channels (raw I/Q samples), and you should use the GNU Radio flowgraph called rtp_source_nws_iq.grc, because in this case GNU Radio has to do the demodulation of the NBFM signal from the I/Q data stream

That debug line that I suggested you add after line 138 in lib/source_impl.cc does add a significant overhead because it prints a new info message to the terminal for every packet received, so I would comment it out for now (and uncomment it later if we need to).

Tom is seeing a significant number of those 'Dropped N samples' messages with his setup, while you don't mention them, so I was wondering if, after you remove that debug line, you could try running GNU Radio again (with the flowgraph that matches the mode line in radiod@rtlsdr.conf), and see what it does.

Also I see that Phil hasn't made any changes to 'pcmcat.c' or 'multicast.c' in the last week or two, so at this point I believe that, if you are running a version of 'ka9q-radio' that is from say the last 10 days or less, you should be OK (i.e. I wouldn't worry too much about making sure it is the most recent version).

Franco

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fventuri fventuri

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@fventuri @N5BRG