Comment 2 for bug 1879529

It has to do with OGG Codec and icecast2.

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.

[u]Streaming MP3 96kbps[/u] :
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.

[u]Streaming OGG 96kbps[/u] (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 [u]play that recording[/u] of last streaming in Totem : no expansion of silence. 50+ seconds between the fades (5" on each side, seems good).

I [u]stream that recording OGG 96kbps[/u] 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 [u]stream the recording OGG 128kbps[/u] 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, [u]streaming OGG 256kbps[/u], 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, [u]streaming MP3 320kbps[/u], 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 [b]OGG, whatever the bitrate, using Icecast2 2.4.2, players transform 60 sec of silence[/b]
- either into [b]75~80 sec (+25%)[/b] (lag jumps from 6 til 22 or 27 seconds ; Radiotray / Rythmbox)
- or [b]105~110 seconds (+90%)[/b] (lag jumps from 8 to 53 seconds ; all browsers).
… and that [i]this isn't the case in MP3[/i], whatever the bitrate.

Then I tried [u]doubling the silence[/u] 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.