Silence in streaming (icecast) expand 50% longer than played

Fixxx your Mixxx

Moderator: garth

Silence in streaming (icecast) expand 50% longer than played

Postby mbrouillet » Wed May 20, 2020 3:56 pm

Hello,

In a nutshell, I let AutoDJ play three songs, the one in the middle being 60 seconds of silence. The resulting Icecast broadcast has close to 90 seconds of silence.

Lag (measured playing a short sample) goes from 4 seconds to 30 seconds after the silence. It doesn't matter if silence is : a file with silence / volume set to zero / a pause of 60 seconds.

Any idea ? Technical details in the bugreport https://bugs.launchpad.net/mixxx/+bug/1879529

Marcel.
mbrouillet
 
Posts: 42
Joined: Sun Jun 09, 2019 10:32 am

Re: Silence in streaming (icecast) expand 50% longer than pl

Postby JosepMa » Thu May 21, 2020 5:32 pm

It is difficult to know if this problem is a problem with the icecast implementation, or with the vorbis codec or the html player.

Could you make some other tests recording the output to disk with ogg and play that on a player, or also use a desktop app to play the stream instead of the web player?
JosepMa
 
Posts: 865
Joined: Sat Oct 10, 2015 7:02 pm

Re: Silence in streaming (icecast) expand 50% longer than pl

Postby mbrouillet » Thu May 21, 2020 8:47 pm

I already know it's not a player issue (I was streaming for a zoom conference, and people all over had issues).

It has to do with Codec. I play the same sequence with AutoDJ(5' fade) : a 60 second silence track in sandwich between two tracks. I listen to the broadcast on a different PC on radiotray, and on my phone on Samsung Browser. During the play of the first track I play a short bell (sample), start a stopwatch, and measure when it comes out of the phone and the phone. I reload the page, or stop/start the radio and do several lag measures. I do these measures before the 60 sec silence and after.

Streaming MP3 96kbps :
Before the silence track : Radiotray lags 8"43 ; Samsung browser lags 13"22
After the silence track : Radiotray lags 8"51 ; Samsung browser lags 13"63
Basically measure errors, sub-second.

Streaming OGG 96kbps (recorded, and available here for 14 days : https://fromsmash.com/MixxxOggBlank) :
Before the silence track : Radiotray lags 6''29 (second measure 7"26) ; Samsung browser lags 6"29 (other measures 9"83, 9"40 after page reload)
After the silence track : Radiotray lags 27"84 (second measure 27"91) ; Samsung browser lags 53"80 (then 53"56)

I play that recording of last streaming in Totem : no expansion of silence. 50+ seconds between the fades (5" on each side, seems good).

I stream that recording OGG 96kbps and I use Firefox on the listener PC, and Chrome on the phone :
Before the silence track : Firefox lags 6''28 (second measure 7"96 then 8" after page reload) ; Chrome lags 6"28 (other measures 7"96 after page reload)
After the silence track : Firefox lags 53"52 (second measure 54"16) ; Chrome lags 52"26 (then 52"92)

I stream the recording OGG 128kbps and I use Rythmbox on the PC and Chrome on the phone :
Before the silence track : Rythmbox lags 6''28 (second measure 7"96 then 8" after page reload) ; Chrome lags 6"28 (other measures 7"96 after page reload)
After the silence track : Rythmbox lags 21"24 (second measure 21"26) ; Chrome lags 52"47 (then 52"39)

I go back to the orignal tracks, and let autoDJ run, streaming OGG 256kbps, and I use Chromium on the PC, and Firefox on Android :
Before the silence track : Chromium lags 4" ; Firefox Android lags 4"
After the silence track : Chromium lags 54" ; Firefox Android lags 52"

I go back to the orignal tracks, and let autoDJ run, streaming MP3 320kbps, and I use Chromium on the PC, and Firefox on Android :
Before the silence track : Chromium lags 9" ; Firefox Android lags 3"
After the silence track : Chromium lags 9" ; Firefox Android lags 3"

So we can safely say that in OGG, whatever the bitrate, using Icecast2 2.4.2, players transform 60 sec of silence
- either into 75~80 sec (+25%) (lag jumps from 6 til 22 or 27 seconds ; Radiotray / Rythmbox)
- or 105~110 seconds (+90%) (lag jumps from 8 to 53 seconds ; all browsers).
… and that this isn't the case in MP3, whatever the bitrate.

Then I tried doubling the silence to twice the 60 silence track in the sandwich. OGG 256 :
Before the silence track : Radiotray lags 3"90 ; Firefox Android lags 3"60
After the silence track : Radiotray lags 24"76" ; Firefox Android lags 1'18"96

So I presume there are two ways of reading the stream. The radio players maintain a constant lag of 20+ seconds ; the web browsers add a more proportional lag +65 ~ +90%.

Note that in these tests, I just loaded the stream address in the browsers, so I did not specify preload or no preload (as opposed to what I described in the bugreport, specifying the HTML attribute preload=none).

Marcel.
mbrouillet
 
Posts: 42
Joined: Sun Jun 09, 2019 10:32 am

Re: Silence in streaming (icecast) expand 50% longer than pl

Postby JosepMa » Fri May 22, 2020 5:46 pm

Ok.

I've been able to reproduce it. Setting a local icecast 2 server, configuring mixxx for icecast 2 and ogg vorbis and listening on a desktop application, the silence gets longer.
I was also able to record it to disk in ogg vorbis (not in wav like you did), and the silence length is correct then.

What I see is that vorbis uses 0kbps for these silence parts, and that packets are sent to the icecast server when a Ogg "page" has been filled.
The problem is that this means that it takes more than realtime to generate this, and the server is waiting without receiving a signal.
To the listeners, it is as if their internet connection was too slow and was waiting for the next packet.

We should be able to tell the encoder to either don't go that low in bitrate to prevent this from happening, or forcing it in some way to write a packet when enough samples are sent in.
In fact, I believe we don't setup it correctly. At 128kbps with your audio it was using up to 200kbps.


Can you open a bug at https://bugs.launchpad.net/mixxx so that the developers can track this and fix it?

Note for developers:
encodervorbis.cpp, initEncoder, vorbis_encode_init max_bitrate, average_bitrate, minimum_bitrate.

Detect if we are encoding to file or to stream, and use max_birate= average_bitrate*1.5, and minimum_bitrate = average_bitrate/4 ( i.e. for 128kbps , max 192, min 32. for 64kbps, max 96, min 8)
JosepMa
 
Posts: 865
Joined: Sat Oct 10, 2015 7:02 pm

Re: Silence in streaming (icecast) expand 50% longer than pl

Postby JosepMa » Sat May 23, 2020 8:45 am

I forgot to add the screenshots.
One can observe that the audio is cut (which means the packet is received too late to not skip). That skip is what causes the silence to be longer.
ogg-silence-first.png
ogg-silence-first.png (44.77 KiB) Viewed 68 times

ogg-silence-second.png
ogg-silence-second.png (1.75 KiB) Viewed 68 times
JosepMa
 
Posts: 865
Joined: Sat Oct 10, 2015 7:02 pm

Re: Silence in streaming (icecast) expand 50% longer than pl

Postby mbrouillet » Mon May 25, 2020 1:13 pm

Thank you so much for your time reproducing it.
I conceptually understand from your writing that, using 0kbps, it somehow leads to an infinite transmission time (division tends to zero).
Sorry for recordings in Wav, I missed that part indeed :-).
I did open a bug report, and I believe you've changed the status of it. Please tell me if you still want me to do something on the bugreport. I'd be happy to.
Marcel.
mbrouillet
 
Posts: 42
Joined: Sun Jun 09, 2019 10:32 am


Return to Troubleshooting & FAQ

Who is online

Users browsing this forum: No registered users and 61 guests