[LAU] Buffering, soundcard clocks, synchronization, streaming

[Len Ovens]

On Thu, 6 Nov 2014, Ken Restivo wrote:

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

There are people around that would know more surer than I do. But I am 
pretty sure I have read (on this list in fact) that the encode/decode of 
mp3, opus or ogg files/streams is not sample rate locked at all. As part 
of the filtering in the decoding, the audio is resampled anyway and the output is 
then locked to the audio IF in the machine. I have not had any problems 
playing back 44k1 streams on my 48k HW. Reading through the opus dev guide, 
it says that opus works at 48k and the dev should provide resampling at 
either end to match the HW. I am not sure if there is resampling 
done in pulse on it's way through, but it shouldn't have to. The decoder 
should do that already. There is timecode of some sort in the stream I 
think (could be wrong)  Where each packet of audio contains so many msec 
of audio. I don't know how the stream deals with this with two wall clocks 
not being in sync or if that matters. The codec should be able to correct 
for that though, within the resampling it does anyway.

When a stream is fed to a server that feeds streams to clients, The server 
(LS in this case) should be just passing the ready made stream along. It 
should not be feeding it according to the sample rate or even the the time 
value of the individual packets. The buffering is just there so the feed 
has a head start on the stream in case some packets get lost/delayed and 
need to be resent (in this case the latency is long enough for this to 
happen). If the stream is not keeping up with streamer's send rate, then 
there is a network problem. Testing should be done with non-audio file 
sends to verifiy the network segment can actually keep up with the audio 
bitrate being used. I am assuming your network is using a standard bitrate 
for everyone, but if there are sources on slower net segments, it may be 
worth while using reduced bitrates. See if running at 120 bps instead of 
128 makes a difference.

--
Len Ovens
www.ovenwerks.net