On Thu, Nov 06, 2014 at 02:28:32PM -0800, Len Ovens wrote: > 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. > 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
