Live365 audio glitches

[zdooder]

Recently there has been some signal analysis done (mainly by Shargo but with some input from Cactus and myself) and it appears that levels aside, there are some glitches in the Live365 stream.

For instance, in my show today, I've compared the recorded MP3 stream from Live365 to my locally recorded stream, and while I don't expect them to be identical, there's a clear "glitch" (mp3 coded desync?) here:



I've attached MP3 excerpts that you can listen to to hear the glitch. It's important to note, however, that this isn't a rare occurrence. If you listen you'll hear it regularly during the stream. I think people don't generally hear it on live broadcasts because we're very twitch-heavy and it doesn't occur there.

Anyway, I don't know if we can do anything about it. But it seemed like it was worth noting.

(And special thanks to Shargo for making recordings and pushing to get this noticed. Also to Shargo and Cactus, feel free to chime in if you have better explanations for what's going on.)

z

[shargo]

I finally found the same sequence in my recording (next time, please post a time stamp...).
While my recording of the L365 stream contained similar glitches in some places this song hadn't any. So as I started to suspect they are the result of dropped packets of the individual stream or the local player messing things up, not caused by the path to L365 or their processing.

That said, it's still sounds like it's been clipped at some point.

I'll try to keep an eye on a couple of more shows to see if several live shows still runs very hot especially compared to the rotational stream.

[zdooder]

Dropped packets in a TCP stream won't result in audio glitches unless something very weird is going on. The nature of TCP is that it literally can't continue until the dropped packet is retransmitted and processed -- which might result in buffering (where the audio stops until the dropped packet is finally received) -- but not resync glitches like we're hearing. This is why I have thought that Live365 must be using some kind of unreliable (e.g. UDP) distribution mechanism internally. Such a protocol CAN drop packets and continue and events in that sort of protocol would result in something like what we're hearing. I would dispute that this is a "local player" problem given that we're using different local players AND I don't hear any glitches on other MP3 streaming stations AND I never used to hear them on BozRadio either.

To be clear, my hypothesis is that Live365 is using some kind of regional distribution network with an unreliable transport (presumably for efficiency), e.g.

image_2021-10-19_081526.png (24.45 KiB) Viewed 22017 times

If the mcast/UDP distribution drops packets randomly (and possibly differently for each "region" in the CDN) it could fit the observed model that we're seeing. Another possibility, though, is that Live365 may be re-encoding the stream somewhere -- but it's unclear to me how this results in different "glitches" for different listeners unless they're re-encoding it *everywhere*. (And I'll confess that I don't really understand how you'd implement this -- you'd need multicast-over-UDP-over-VPN? to get the packets into the different physical regions, and at that point I don't think multicast really gets you anything other than maybe better performance when you have dropped packets?)

(Obviously each "region" may well be multiple servers and/or additional layers of audio relays; I've tried to keep it simple here. This model is also based on the fact that the observable "lag" in the stream varies from listener to listener and from region to region, suggesting different relays with different performance characteristics. But, that's also purely hypothetical.)

[shargo]

One thing doesn't exclude the other

While you are technically correct about how TCP works I sincerely doubt that's the whole story. If packets weren't allowed to be dropped / ignored the stream would stop as soon as a single packet is missed - and that's not the case.
Question is just on which layers this processing happens.
And as you say "TCP doesn't allow it" this must happen at a higher level and thus likely a larger chunk of data being discarded which also would explain the rather characteristic "blip" that's often is heard. Combine that with lack of proper filtering and we get the sudden clipping due to a to sudden change in the reproduced audio.

Now I'm wondering if different clients handle this in different ways (discarding missing data / filtering) or if it is bound to the streaming format... So far I've been using VLC to grab my samples but I think I'll try to setup some other applications to see if the result is the same.