10 Nov
2014
10 Nov
'14
10:14 p.m.
On Thu, Nov 06, 2014 at 02:28:32PM -0800, Len Ovens wrote:
On Thu, 6 Nov 2014, Ken Restivo wrote:
Turns out I've captured in the wild, one guy streaming from California (over a WIFI
ISP, no less), whose buffer *increases* as his show goes along. And a guy in Bulgaria
whose buffer also increases as his show goes along. So I am no longer inclined to believe
this has anything to do with network latency or geography.
So far the sound-card-clock-rate theory best fits the data, AFAICT. Not sure what to do
about it, but I'll look into it.
BTW, I'm not sure what Icecast2 does or does not do with the Ogg granuleops and
samplerate data, but I know that Liquidsoap transcodes the audio to PCM and re-encodes it
(which is how it can take Vorbis in and spit out MP3 or vice versa), and doesn't
appear to resample it-- it'll put out 48k if you give it 48k, and 44.1k if you give it
44.1k.
Also, too, man does MP3 suck. Ogg Vorbis sounds so much better. Will play with Opus a bit
next week.
-ken
On Thu, Nov 06, 2014 at 07:00:59PM +0100, David
Olofson wrote:
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.
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'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.