[BUG] Choppy/garbled/audio dropout on Raspberry Pi 5 using SoapySDR

[ludwigloh]

I use RTLSDR-Airband 5.0.9 on a Raspberry Pi 5. I have a problem with garbled/choppy/missing/scrambled words in the audio output. Not all the time, but with a few minutes intervals. I build RTLSDR with the "native" flag using a fresh install of Raspian (Debian 12 bookworm).

To prevent the CPU governor to decrease CPU freq, in the boot config I have set arm min freq to 2400 and verified that it it is stable on 2400mhz. htop command to watch CPU core load gives me almost never more than 10% on any core, at any time.

Here is an example audio file, a compilation of several audio faults extracted from a 30 minute window.
https://file.lohelectronics.se/repository/esslproblems.mp3

If of any interest, in the stats file, I can see this

output_overrun_count{device="0"} 21263
output_overrun_count{device="1"} 20599

after a few days of running.

Here is my config file

multiple_demod_threads = true;
multiple_output_threads = true;
stats_filepath = "/var/tmp/rtl_airband_stats.txt";
fft_size = 256;
devices:
({
type = "soapysdr";
device_string = "driver=airspyhf,serial=c852978035b425f6";
sample_rate = 0.384;
mode = "scan";
channels:
(
{
freqs = ( 118.280,118.405,118.805,120.500,129.800,133.100,132.955,133.260,133.705,135.850 );
labels = ( "Sweden 118.280", "Sweden 118.405", "SAAB TWR", "Guard", "129.800", "133.100", "Ostgota 132.955", "Sweden 133.260", "Sweden 133.705", "Ostgota 135.850");
afc = 1;
squelch_snr_threshold = (20, 15, 15, 25, 15, 15, -1, -1, -1, 15);
outputs: (
{
type = "icecast";
server = "audio-in.liveatc.net";
port = 8010;
mountpoint = "essl";
send_scan_freq_tags = true;
name = "ESSL Twr/Radar/Control";
description = "ESSL Linkoping, Sweden";
genre = "ATC";
username = "";
password = "";
}
);
}
);
},
{
type = "soapysdr";
device_string = "driver=airspyhf,serial=36524c8035b42590";
sample_rate = 0.384;
mode = "scan";
channels:
(
{
freqs = ( 118.280,118.405,120.355,120.500,129.800,133.100,132.955,133.260,133.705,135.850 );
afc = 1;
squelch_snr_threshold = (20, 15, -1, 25, 15, 15, -1, -1, -1, 15);
outputs: (
{
type = "icecast";
server = "audio-in.liveatc.net";
port = 8010;
mountpoint = "essp2_twr_app_ctrl";
send_scan_freq_tags = true;
name = "ESSP Twr/Radar/Control";
description = "ESSP Norrkoping, Sweden";
genre = "ATC";
username = "";
password = "";
}
);
}
);
}

[nrussell88]

I have found it easiest to narrow down where the issue is (network or machine) by adding a "file" output to your outputs and seeing if the audio experience is the same or different. I would use a file output on both devices.

You will need to create a directory for these files to go into and then note the file path. Then you can do something like the below--

outputs: (
{
type = "icecast";
server = "audio-in.liveatc.net";
port = 8010;
mountpoint = "essp2_twr_app_ctrl";
send_scan_freq_tags = true;
name = "ESSP Twr/Radar/Control";
description = "ESSP Norrkoping, Sweden";
genre = "ATC";
username = "";
password = "";
}
{
type = "file";
directory = "/your/path";
filename_template = "TOWER";
}

Syntax and explanations can be found here-
https://github.com/charlie-foxtrot/RTLSDR-Airband/wiki/Configuring-file-outputs#syntax

If you decide to keep the file outputs after you are done troubleshooting, you can set up a quick bash script to clean the folder every X minutes or days to prevent your storage from filling up. Some brainstorming on this here

[ludwigloh]

Hi Thanks, said and done, its recording to file now. I will listen to the files in a couple of hours and post the results. Best regards, Ludwig Den ons 13 mars 2024 kl 19:55 skrev Nick Russell ***@***.***>:

…

I have found it easiest to narrow down where the issue is (network or machine) by adding a "file" output to your outputs and seeing if the audio experience is the same or different. I would use a file output on both devices. You will need to create a directory for these files to go into and then note the file path. Then you can do something like the below-- outputs: ( { type = "icecast"; server = "audio-in.liveatc.net"; port = 8010; mountpoint = "essp2_twr_app_ctrl"; send_scan_freq_tags = true; name = "ESSP Twr/Radar/Control"; description = "ESSP Norrkoping, Sweden"; genre = "ATC"; username = ""; password = ""; } { type = "file"; directory = "/your/path"; filename_template = "TOWER"; } Syntax and explanations can be found here- https://github.com/charlie-foxtrot/RTLSDR-Airband/wiki/Configuring-file-outputs#syntax If you decide to keep the file outputs after you are done troubleshooting, you can set up a quick bash script to clean the folder every X minutes or days to prevent your storage from filling up. Some brainstorming on this here <https://stackoverflow.com/questions/249578/how-to-delete-files-older-than-x-hours> — Reply to this email directly, view it on GitHub <#467 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOMVQDDYVB4N4U2H65NTU5TYYCOLPAVCNFSM6AAAAABEPGZ7MGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJVGM4DSMJWGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- *Ludwig Loh* VD / CEO Loh Electronics AB Direct +46 (0)735 88 80 47 Main +46 (0)19 70 70360 ***@***.*** http://www.lohelectronics.se

[ludwigloh]

I must say that I am pretty confident that it is network related somehow. I have listend to a lot of the recorded files and there is absolutely no choppy or garbled audio in the files on disk.

The problem came instantly after changing from a normal PC to RPi 5. Its the same internet connection 20/10mbps.

Another observation that also was reported by a listener was that VLC has "problems" with the feed, the "seconds" that ticks in VLC often skip from x:2 directly to x:5 for instance. Maybe not related, but an observation. Also VLC seems to have some kind of issue buffering the feed.

[nrussell88]

I must say that I am pretty confident that it is network related somehow. I have listend to a lot of the recorded files and there is absolutely no choppy or garbled audio in the files on disk.

The problem came instantly after changing from a normal PC to RPi 5. Its the same internet connection 20/10mbps.

Another observation that also was reported by a listener was that VLC has "problems" with the feed, the "seconds" that ticks in VLC often skip from x:2 directly to x:5 for instance. Maybe not related, but an observation. Also VLC seems to have some kind of issue buffering the feed.

I agree with you it is likely network related. Are you using a WiFi or wired Ethernet connection to the Pi?

[ludwigloh]

Hi It’s wired to the router, i checked the link speed again with speedtest, gave me 40/30 with 35-40ms latency. Best regards Ludwig *Ludwig Loh* VD / CEO Loh Electronics AB Direct +46 (0)735 88 80 47 Main +46 (0)19 70 70360 ***@***.*** http://www.lohelectronics.se fre 15 mars 2024 kl. 07:22 skrev Nick Russell ***@***.***>:

…

I must say that I am pretty confident that it is network related somehow. I have listend to a lot of the recorded files and there is absolutely no choppy or garbled audio in the files on disk. The problem came instantly after changing from a normal PC to RPi 5. Its the same internet connection 20/10mbps. Another observation that also was reported by a listener was that VLC has "problems" with the feed, the "seconds" that ticks in VLC often skip from x:2 directly to x:5 for instance. Maybe not related, but an observation. Also VLC seems to have some kind of issue buffering the feed. I agree with you it is likely network related. Are you using a WiFi or wired Ethernet connection to the Pi? — Reply to this email directly, view it on GitHub <#467 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOMVQDGJWQII5IF4X5GPX7TYYKHRXAVCNFSM6AAAAABEPGZ7MGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJZGAYTKNZQGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ludwigloh]

I might have rushed to a conclusion earlier. I have listened to even more recorded files and the choppy audio is present there as well. Its not so frequent anymore as it was 5 to 14 days ago. Maybe this rules out network after all.