Webradio random drop outs / interruptions

[Roland-B]

Hi Rern,

Happy new year, thanks for bringing us this awsome build and may it continue for another year at the least :)

I mentioned this previously and thought it was fixed, but on listening to Webradio now for longer periods I get random drop outs / interruptions of about a second of silence. I have gone back to previous build of Rune and the radio is fine so is not my internet conection (using LAN cable) or the station (BBC Radio 6). To me it appears as if is being limited by processor or come kind of processing somewhere else in rune interfering/using cpu. I can make it get worse when it occurs by switching tabs in a web browser (Firefox and Chrome) from rune to another tab and back and forth, back and forth quickly, so "seems" to be throttling/limiting of some kind as CPU on system page seems to be low.

Thanks for your assistance with this as always

RolandB

rAudio 1 • 20210101
Raspberry Pi 4 Model B Rev 1.2
BCM2711 • 4 Cortex-A72 @ 1.5GHz • 4GB
E30
5.4.83-3-ARCH

[R101G]

Just a suggestion, but have you checked the CPU temperature? I had so many problems using the Pi4 that I went back to using a Pi3.

[Roland-B]

@R101-Github

Thanks for suggestion, most appreciated bud, but is fine when I use previous build and works fine for all other uses of current build inc large/ quality flac files, should be no issue for a 320Kbps stream. Also is running cooler than a polar bears toe-nails at 40.9 °C in use on average as have aluminium case with heat sinks.

RolandB

[klassikmann]

@Roland-B I made the same experience (random drop outs) on BBC Radio 3 since some weeks. I'll investigate the stream to sort out rAudio as the cause. I'll come back if I have some insights.

@R101-Github CPU temperature is moderate (51° C).

[klassikmann]

@Roland-B Could you please post the "BBC Radio 6" URL you are using?

[Roland-B]

Hi @klassikmann,

http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/uk/sbr_high/ak/bbc_6music.m3u8

I have have tried lots of different stations other than BBC and they all eventually do it, even the station that comes as standard with the build. I use the radio all day while working from home and it became so annoying I went back to re6 which works perfectly for me for now.

Thanks for you assistance in trying to find a fix.

RolandB

[ceejayemm]

Roland

I use the following urls for BBC Radio 2 and BBC 6 Music and can't say I have noticed dropouts (RPi 3B+, Merus Audio Amp)

BBC 6 Music
http://as-hls-uk-live.bbcfmt.s.llnwi.net/pool_904/live/uk/bbc_6music/bbc_6music.isml/bbc_6music-audio%3d320000.norewind.m3u8

BBC Radio 2
http://as-hls-uk-live.bbcfmt.s.llnwi.net/pool_904/live/uk/bbc_radio_two/bbc_radio_two.isml/bbc_radio_two-audio%3d320000.norewind.m3u8

Chris

[klassikmann]

@Roland-B The BBC radio live streams are no "ordinary" streams (as the "Radio Paradise" ones) but "HTTP Live Streams" (HLS), see https://en.wikipedia.org/wiki/HTTP_Live_Streaming.

What does it mean? The outmost .m3u8 (bbc_6music.m3u8) contains a link to another .m3u8 (bbc_6music-audio%3d320000.norewind.m3u8) which describes the first portions containing consecutive few seconds (here 6 sec) of "AAC LC" audio contained in a "MPEG2 Transport Stream" (.ts) which a forwarded by MPD to the ffmpeg plugin for demuxing the TS-container and playing the AAC LC.

If ffmpeg is not capable to fetch in time a portion of a .ts then six seconds of audio are missing.

I can't comment to your observation that re6 is "stutter-free" because I switched to rAudio (but perhaps I burn a spare sdcard with the latest re6 for testing).

@rern Are you aware of any change in the relationship mpd <-> ffmpeg during the last weeks?

EDIT: Correct "MPEG1 Transport Stream" to "MPEG2 Transport Stream"

[Roland-B]

I can confirm the same behavior.
I also observe dropouts when playing from NAS via SMB (1 Gbit/s) or internal m.2 SSD (>250 MByte/s in an argonONE case). I first suspected HiRes FLAC and DSD. However, dropouts also occur with 128k mp3. Temperature is around 50°C.
I also tested via HDMI and cross swapped all cables to rule out infrastructure errors. To exclude effects on the USB bus I tested without internal disk. Without success.
On RPi3 and RPi2 with e3 and the same DAC and the same sources everything runs to full satisfaction.
The journal is full with "taskset[439]: alsa_output: Decoder is too slow; playing silence to avoid xrun".

Greetings from Austria

Hi @findnix,

Thanks for that info, using the the detail you provided I have figured out how to check the logs and have the same, hopefully this info helps @rern figure the cause.

Jan 08 09:26:06 rAudio taskset[430]: ffmpeg/hls: skipping 1 segments ahead, expired from playlists
Jan 08 09:26:08 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:26:35 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:27:02 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:27:32 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:27:46 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:27:47 rAudio taskset[430]: ffmpeg/hls: skipping 1 segments ahead, expired from playlists
Jan 08 09:28:13 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:28:18 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:29:14 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:29:20 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun
Jan 08 09:29:28 rAudio taskset[430]: alsa_output: Decoder is too slow; playing silence to avoid xrun

Edit: Also have just tested a brand new microsd card just in case was issues with slow read/write causing issue. No change.

RolandB.

[ceejayemm]

I am not seeing any of these ' Decoder too slow' errors on my installations. Both my DACs are HATs and are attached directly to the GPIO pins of my RPIs. Could it be that these errors are from a USB based DAC ?

Chris

[Roland-B]

@ceejayemm

I wouldn't have thought so as all works perfect on R e6. The only difference for me is the new build of rune (rAudio1), and the only other factor/difference would have been the alternate microsd card at fault which I have just tested.

RolandB

[ceejayemm]

This might not be a RAudio problem. There are similarly reported issues in the Moode forums, see:

http://moodeaudio.org/forum/archive/index.php?thread-518.html

And in the MPD Github Issues:

MusicPlayerDaemon/MPD#206

Chris

[Roland-B]

All issues seem to be reported around 2018. R e6 is from late last year and works fine and it was only updated to RAudio-1 not very long ago. From what I can tell the issue seems to be for the build of rAudio-1 for the Pi4 from reading through here, and hopefully @rern should be able to work out what has changed between his builds for Pi4 between r e6 and rAudio-1, whether it be code or a software/kernel update and fix/revert the change.

RolandB

[klassikmann]

Obviously we are discussing different issues.

Using my configuration - RPI 3B + HifiBerry Digi+ Pro (not a DAC but a digital-out) - I'm suffering drop-outs at the BBC Radio HLS 320kb AAC LC streams only. No problems with "classical" streams, even with the streams generated by my SAT-TV embedded in .ts (MPEG 2 Transport Stream). btw. ffmpeg needs about 7 seconds to analyze and demux the streams before playing starts.

For BBC Radio 3 HD there are two different sources available both provided by the ffmpeg plugin of mpd. One is the above mentioned HLS, the other one is a "classical" AAC stream sharing the same content (320kb AAC LC) as the HLS and playing smoothly.
Another difference: The AAC stream starts immediately, the HLS needs between 10 to sometimes 40 seconds before playing starts.

Same effects for both stream types apply if I use ffmpeg directly, i.e. outside of rAudio, on ArchLinux and on Ubuntu 20.10. Therefore I believe that the cause of my problem lies outside rAudio or re6 where I detected the same issues.

[Roland-B]

@klassikmann

Yup, appears so as the fix for Pi4 in todays update has done the trick for my issue. I hope you manage to figure out the cause of your issue, as know how annoying the interruptions can be.

RolandB

[klassikmann]

@Roland-B My problem is still there. But I'm currently working through the ffmpeg logs.

[Roland-B]

@rern

Currently testing todays (20210109) update with "Fix - Audio drop-outs on Raspberry Pi 4", sounding good so far, with no interruptions :)

Only listened for around 10 mins so far and usually encountered the issue before this, but will listen for an extended period to confirm.

Thanks.

RolandB

[findnix]

Thank you @rern
I can confirm that. Still sounds good now after an hour.
I'm still testing, but I don't expect any dropouts.

Thanks again
Ronald

[Roland-B]

@rern

After extended listen no interruptions and no errors in journal logs. Thanks very much as always.

RolandB