Player Synchronisation and Seeking - Protocol Handler Support

[expectingtofly]

A bit of background :

On my BBC Sounds app it has an audio protocol handler dealing with chunked audio data through Mpeg-dash to play live radio.
I'm taking advantage of the chunked audio to provide a useful live radio rewind facility. Users can essentially seek to any point in the past within the currently playing programme using the standard LMS seek controls.

This is meant to be a useful and convenient function that is approximate. The seeking logic is converted into a specific dash audio chunk, so it is only accurate within 6.4 seconds, the size of an audio chunk. Which is good enough, from the users perspective.

The problem :

A user has complained that he is experiencing regular audio dropouts and hiccups. He has 3 players that are synchronised and playing the BBC Sounds live stream.
He has shared a log file with me and that is showing that his players are calling the seek facility on the BBC sounds protocol handler to rewind the live stream by a few seconds every hour so. This is what is causing his audio gaps and hiccups as the protocol handler will go ahead and do the seek which will only be accurate within 6.4 seconds of the precise micro second it is asking for.

I wonder if someone can please help me with this, as I know very little about the synchronisation logic. So my questions are :

1. Does the player synchronisation logic use stream seeking to keep the players in sync?
2. If it does, how can I prevent it trying to use that on the BBC Sounds seeking which is not intended to be used for that purpose?

Thanks.

[mherger]

I'm sorry to say that this is definitely not in my comfort zone...

--

Michael

[philippe_44]

AFAIK, synchronization does not use seek at all for sync. All it does is sending the players commands to either consume a few ms of decoded audio or add a bit of silence.

Now, what can happen is that if a player disconnects, upon reconnection LMS tries to get all to restart synchronized and for that it interrupts the stream, stops players, seeks where it want to restart from and restarts. As far as players are concerned, it’s a new track, no a sync d’ajustement event.

[expectingtofly]

AFAIK, synchronization does not use seek at all for sync. All it does is sending the players commands to either consume a few ms of decoded audio or add a bit of silence.

Now, what can happen is that if a player disconnects, upon reconnection LMS tries to get all to restart synchronized and for that it interrupts the stream, stops players, seeks where it want to restart from and restarts. As far as players are concerned, it’s a new track, no a sync d’ajustement event.

Ah, that makes perfect. Many thanks for the explanation.