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@xxxxxxxxxxx> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
