6 Nov
2014
6 Nov
'14
7:20 p.m.
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(a)restivo.org> wrote:
[...]
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).
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.
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.