[Icecast] Clocks drift again

[Greg Ogonowski]

Simple streaming is fundamentally flawed this way.
"The man with two clocks, does not know what time it is."

Your source is clocked from one crystal in your source sound card, and
played back on the basis of the clock crystal in the client sound card.
There is nothing to say or keep these crystals locked to the same exact
frequency, which is REQUIRED to maintain no clock drift.
Unless the player software specifically deals with modulating a sample-rate
converter, which most, if any, players do not, sooner or later, the stream
will either over or under buffer and cause unpredictable results. The amount
of time it will take for this problem to actually occur will be determined
by the difference in clock frequency between the source and client clocks.
So, "your mileage will vary."

There is currently no way to send synchro clock in a SHOUTcast or Icecast2
stream that I am aware of. Even if there was, the client player would need
to support this specifically.
The easiest way to deal with this with the current architecture, is write a
player that can approximate clock recovery. This will only be an
approximation, but better than nothing at all.

-greg.
Orban



-----Original Message-----
From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Sylvain Le Beux
Sent: Friday, 31 May, 2013 14:34
To: icecast at xiph.org
Subject: [Icecast] Clocks drift again

Hi All,

Sorry again to bother you with this but there is really something I don't
fully understand about client/server clock syncs.
If I connect to the stream with a fresh browser, I can measure between
5-10 secs latency.
I keep listening to it for while, and the delay between server and client
grows as listening is going on.
As pointed out Philipp yesterday to me, it's approximately a 5% drift,
apparently caused by the client audio card clock.
But, then since there are no cuts in the sound as I am listening, it means
the audio rate is lower than the 22kHz of the files, right ?
And a 5% drift at 22kHz is around 1kHz difference ! And even if I did not
properly measured this behavior, I am not subjectively able to hear a
difference in the output.

So, what are the solutions for locking clocks so that the latency is
constant ?

Sorry if I don't understand properly.
Best.

Sylvain

_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast