Re: [LAU] Buffering, soundcard clocks, synchronization, streaming

On Thu, Nov 06, 2014 at 11:32:15AM -0500, Joe Hartley wrote:
> On Thu, 6 Nov 2014 03:35:39 -0800
> Ken Restivo <ken@email-addr-hidden> wrote:
>
> > Now, I've been told that the buffer problem is due to clock synchronization on soundcards. Some soundcards on't stream exactly at 44.1khz, they're like 44.0Khz, and that causes a buffer that gradually declines in size, as it's been explained to me.
> > [ snip ]
> > But what about this business with the sound cards? Is that a red herring?
>
> Maybe I'm just undercaffeinated, but this sounds like complete horse$#!+ to
> me. By the time the Liquidsoap server is taking the stream, the source's
> soundcard is already out of the picture. It's encoded the audio and is
> pushing it out to the network.
>
> > I'm told that the power grid AC mains sync is not uniform across North America and that the east coast is at 60.1Hz or similar, the west coast at 59.9Hz, but that's irrelevant, it's all rectified/regulated +5V by the time the soundcard (and its clock crystal) sees it.
>
> Now this really *is* hooey. European power grids operate at 50Hz, If the
> grid frequency were really an issue, we'd never be able to stream across the
> Atlantic.
>
> It sure sounds like an issue with the network. You might want to try changing
> the buffer type - search the Savonet docs for buffering.kind.

Yep. Thanks. This is what I love about this list; it's great to have additional perspective.

On Thu, Nov 06, 2014 at 05:58:57PM +0100, David Olofson wrote:
> On Thu, Nov 6, 2014 at 12:35 PM, Ken Restivo <ken@email-addr-hidden> wrote:
> [...]
> > Now, I've been told that the buffer problem is due to clock synchronization on soundcards. Some soundcards on't stream exactly at 44.1khz, they're like 44.0Khz, and that causes a buffer that gradually declines in size, as it's been explained to me.
> [...]
>
> Indeed; a pair of sound cards running at (practically) identical
> sample rates is going to take something much more accurate than
> crystal oscillators. Or dumb luck. :-) This is something any streaming
> software needs to deal with (sample drop/insert, or resampling, based
> on buffer status), so there's no valid excuse for this happening.
> Sounds like a bug.
>
>

Why yes, yes it does. Not sure what to do about it; I'm not fluent in ML (which is what liquidsoap is written in).

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.

Another gripe I'm having with liquidsoap is that it does not handle metadata properly, at least on ogg. I'm having to do horrible hacks to attempt to get it to work, and it's a game of whack-a-mole because fixing one bug causes another to manifest.

Are there alternatives to liquidsoap that might work?

-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Thu Nov 6 20:15:03 2014