search

fventuri / gr-rtp

Out-of-tree GNU Radio module for RTP streams
GNU General Public License v3.0
2 stars 1 forks source link

Issue with buffer size #1

Open N5BRG opened 1 year ago

N5BRG commented 1 year ago

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 :warning: 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 commented 1 year ago

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 commented 1 year ago

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

N5BRG commented 1 year ago

Thank for Franco. I will try these things and see what I can learn.

Bob N5BRG

On Sep 4, 2023, at 11:48 AM, Franco Venturi @.**@.>> wrote:

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.cchttp://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

— Reply to this email directly, view it on GitHubhttps://github.com/fventuri/gr-rtp/issues/1#issuecomment-1705531482, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATEQNBHIQYGMXHFD4LIWICDXYYA4BANCNFSM6AAAAAA4JYJCBQ. You are receiving this because you authored the thread.Message ID: @.***>

N5BRG commented 1 year ago

Hello Franco,

I have do more testing here with the I5 computer and the RPi 3B running radiod. I provide you this information in hopes it helps the project development. I would like to see this work.

Testing using an I5 computer to run radiod (one or two` day old version) and a Nooelec RTLSDR

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

this->set_min_noutput_items(1440);

with this line added to code at line 50 I no longer get any output on the terminal for gnuradion while radiod is active. I do hear audio coming through speaker and I can receive a radio.

When I run radiod in a RPi3B with a fresh pull from KA9Q GitHub this is what I see in the gnuradio window I started gnuradio with:

rtp_source :info: noutput_items=4383 noutput_channels=1 sampcount=480 framecount=240

Went back to using the I5 computer for radiod. This time I am using the old original RTLSDR device. I pull down the most current copy of ka9q-radiod and ran with that and gr-rtp with the changes. This is what I see when I do this:

Generating: '/home/bstricklin/projects/gr-rtp/examples/rtp_source_nws_fm.py'

Executing: /usr/bin/python3 -u /home/bstricklin/projects/gr-rtp/examples/rtp_source_nws_fm.py

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. rtp_source :info: New session from @.**@.>:60647, type 116, channels 1, samprate 24000 rtp_source :info: noutput_items=8192 noutput_channels=1 sampcount=480 framecount=480 rtp_source :info: noutput_items=8192 noutput_channels=1 sampcount=480 framecount=480 rtp_source :info: noutput_items=8192 noutput_channels=1 sampcount=480 framecount=480 rtp_source :info: noutput_items=8192 noutput_channels=1 sampcount=480 framecount=480 rtp_source :info: noutput_items=8192 noutput_channels=1 sampcount=480 framecount=480

Earlier I was running with channels = 2 thinking I needed one for ‘I' and one for ‘Q'. I changed this to 1 to match your output.

My radiod conf file for rtlsdr:

Testing the RTLSDR as an IQ source to gnuradio

[global] hardware = rtlsdr status = rtlsdr-status.local fft-threads = 4 iface = eth0 ttl = 1

[rtlsdr] device = rtlsdr samprate = 2048000 description = "VHF on Rtlsdr test" agc = n gain = 140

frequency = 146520000

frequency = 162425000

[RAW]

mode = fm

mode = iq data = iq-pcm.local samprate = 24000 low = -24000 high = +24000 channels = 1 freq = "162m425"

ssrc stands for 'synchronization sourcei'

ssrc = 10

Here is what radio output looks like at start:

(vRMS) (base) @.:~/Projects/ka9q-radio$ ./radiod .@*.**@*.> KA9Q Multichannel SDR main.c last modified Mon Sep 4 19:01:28 2023 Copyright 2023, Phil Karn, KA9Q. May be used under the terms of the GNU Public License Loading config file .@*.**@*.***>... Found 1 RTL-SDR device:

0 (Generic RTL2832U OEM): Realtek RTL2838UHIDIR 00000001

Using RTL-SDR #0, serial 00000001 Found Rafael Micro R820T tuner RTL freq 28,800,000, tuner freq 28,800,000, tuner type 5, tuner gains 0 9 14 27 37 77 87 125 144 157 166 197 207 229 254 280 297 328 338 364 372 386 402 421 434 439 445 480 496 [R82XX] PLL not locked! Disabled direct sampling mode [R82XX] PLL not locked! [R82XX] PLL not locked! VHF on Rtlsdr test, samprate 2,048,000 Hz, agc 0, gain 140, bias 0, init freq 162,425,000.000 Hz, calibrate 0 fftwf_import_system_wisdom() succeeded fftwf_import_wisdom_from_filename(/var/lib/ka9q-radio/wisdom) succeeded rtlsdr thread running Processing [raw] 1 demodulators started 1 total demodulators started Allocating 15 zero-copy buffers service @.**@.>._ka9q-ctl._udp' -> rtlsdr-status.local (239.108.73.252) established service 'raw._rtp._udp' -> iq-pcm.local (239.87.31.236) established

Bob

On Sep 4, 2023, at 11:48 AM, Franco Venturi @.**@.>> wrote:

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.cchttp://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

— Reply to this email directly, view it on GitHubhttps://github.com/fventuri/gr-rtp/issues/1#issuecomment-1705531482, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATEQNBHIQYGMXHFD4LIWICDXYYA4BANCNFSM6AAAAAA4JYJCBQ. You are receiving this because you authored the thread.Message ID: @.***>

fventuri commented 1 year ago

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):

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