[LAU] Buffering, soundcard clocks, synchronization, streaming

[Ken Restivo]

On Thu, Nov 06, 2014 at 07:00:59PM +0100, David Olofson wrote:
> On Thu, Nov 6, 2014 at 6:13 PM, Ken Restivo <ken at restivo.org> wrote:
> [...]
> > I'm told there's a new experimental buffering.adaptive operator in liquidsoap, too. It tries to avoid dropouts by time-shifting the input. Of course, it will probably produce audible effects, like someone putting their finger on a vynil turntable to slow it down. I have a bluetooth adapter here somewhere that takes that strategy for dealing with synchronization, constantly, it's annoying.
> [...]
> 
> Well, that sounds more like an emergency solution that might be better
> than brutal drop-outs on buffer underflows. You're not supposed to
> timeshift anything in the situation you're describing. :-)
> 
> What's happening is that the incoming data was not actually sampled at
> the 44.1 kHz rate you're assuming. That means, if you play it back at
> exactly 44.1 kHz, the pitch is going to be slightly off! So, if the
> receiving code changes the rate (and therefore also the pitch, as long
> as it's plain resampling) to keep the buffer on a steady level, it's
> actually *correcting* the problem, making sure that the audio plays
> back at the sample rate it was actually captured at.

Thanks, this is a fantastic answer, but now I'm more confused. Are you saying the problem is indeed, as I've been told, due to the clock rate being off on the capturing soundcard? And that resampling on the streaming server might be the correct solution? But then if say the server is now sending at 44.0khz (for example) to match the soundcard, we've just moved the mismatch further down the chain, probably to the listeners? Maybe that's OK, but I feel like I'm missing something.

Basically, the chain I have is:

capturing soundcard -> streaming software (BUTT, mostly) -> internet -> liquidsoap input harbor -> liquidsoap icecast output (transcoding!)-> icecast2 -> internet(2) -> listener's player

I have been told that the problem is that the capturing soundcard is running at under 44.1khz (maybe it's a cheap 48khz-only soundcard that is resampling in the driver?), and that as a result the buffer in the liquidsoap harbor is not filling up fast enough to keep up when trying to pull samples out at 44.1 exactly (or faster, maybe it's got a clock running faster?). I'm reading your answer as that you concur with this assessment. Does that seem correct?

This still doesn't explain the geographic difference I've seen in the data though. Basically it seems that either the geographic difference is a red herring (and an amazing coincidence) or the soundcard-clock issue is a red herring (and the problem is actually network-related).

> 
> Now, with this method, if there are connection issues, fluctuations in
> buffer level may result in subtle (as far as that applies to the
> trained ear) pitch variations, which is why it might actually be a
> better idea to do it the simple way, and just drop or insert samples
> instead. In an ideal world, resampling is the correct solution,
> though.
> 
>