[Icecast] IceCast KH - question

[Romain Beauxis]

2013/6/11 Greg Ogonowski <greg at indexcom.com>:
> 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."

That can indeed happen. However, from experience, such clock drift can
take a while to be noticeable, specially when using network operations
and intermediate buffers. Most clocks are synchronous to a pretty good
degree compared to network lags and etc..

I've only ever seen one case where there was a steady drift that was
problematic enough to warrant action..

> 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.

We've implemented a notion of "clocks" in liquidsoap, which allows to
decouple e.g. sound card clock from main CPU clock. Decoupling is
achieved by means of an intermediary buffer. It won't solve the
problem of constant drifting but it can help mitigate issues where one
clock shows temporary lags/hiccups.

R.