Pause in streaming gets icecast clients lagging and confused

[mixxxbot]

Reported by: mbrouillet
Date: 2020-05-19T16:24:45Z
Status: Confirmed
Importance: Undecided
Launchpad Issue: lp1879529
Tags: broadcast
Attachments: MixxxBugReportStreaming.zip

---

[Last point is probably the easiest to reproduce]

Here is what I do :

• start mixxx, connect to icecast2 server (button turns blue)
• open the icecast stream in a browser, press play
• play music in Mixxx. 4" thereafter, I get the music in the browser
• pause Mixxx 10". Browser sound stops (4" delay obviously).
• start playing again. Browser starts playing the chunk where stopped for 1/2" then again 10" of silence, then plays with a delay of 14".
• if reloaded during the pause, the browser page plays the chunk before the pause and then plays silence.

• I get the icecast very confused with major lags in the browser (can be playing a song I was playing 10 min before). Within a minute, when doing three pauses of 10 seconds (measuring with stopwatch), I can get the lag go from initially 4' to 20' or more.

• When I unpause Mixxx, the browser plays instantly (i.e after the expected 4" lag) a fragment of 1/2" that is probably the chunk when paused, then stops again for a long pause, longer than what actually was paused (pause 30' on mixxx -> resulting silence 50' in player).

• Using Wireshark I can see that Mixxx sends null packets continuously when paused (see screenshot with "."). Client is still playing, seconds are changing.

• In Icecast admin web interface I see that total_bytes_sent remains roughly at a constant offset from total_bytes_read.

  • The player is specified to not preload : . JS console confirms this theoretical setting.

• zeroing the volume while letting the musing play (not using the pause button but lowering voulme to zero while playing) yields the same as using the pause.

• playing in autodj a one-minute blank sound (see attached) yields to lag going from 6" (before) to 50' (after). Lag is measured from the moment I play a sample to the moment I hear it. Nothing was touched on the player which continued to play, nor on Mixxx which continued to play the blank for 60 seconds, starting autoDJ fade after 50secs. During that blank file, I see that packets are not to zero but to "U" 0x55 (see second screenshot in AASCI and Hex).

  Mixxx : 2.2.3 (r6750)
  Ubuntu : 18.04.4 LTS (64b)
  Hardware : AMD Athlon, avg load 0.88, 8Gb mem (roughly 50% use)
  Firefox : 76.0.1 (64b),
  Icecast : 2.4.2
  Stream : Ogg Vorbis 96kbps

Attachement : MixxxBugReportStreaming.zip =
adding: Screenshot from 2020-05-19 17-01-23.png (deflated 8%)
adding: Screenshot from 2020-05-19 18-05-23.png (deflated 13%)
adding: Screenshot from 2020-05-19 18-06-01.png (deflated 20%)
adding: 0917.ogg (deflated 67%)

[mixxxbot]

Commented by: mbrouillet
Date: 2020-05-19T16:24:45Z
Attachments: MixxxBugReportStreaming.zip

[mixxxbot]

Commented by: mbrouillet
Date: 2020-05-22T10:46:13Z

---

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.

[mixxxbot]

Commented by: JosepMaJAZ
Date: 2020-05-26T11:50:45Z

---

Explanation of the problem and the way to reproduce at this post on the forums.
Also, hints on what to do to fix it:

https://mixxx.org/forums/viewtopic.php?f=3&t=13423&view=unread#unread