[Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

[David Richards]

On Fri, Jan 7, 2011 at 11:25 PM, Brian Willoughby <brianw at sounds.wa.com> wrote:
> I just thought of something: Given the maximum supported network
> packet size, and the minimum number of channels (probably stereo) for
> a FLAC broadcast stream, it should be possible to calculate the
> absolute longest time that a single network packet could span.  Once
> you know that time, you could simply double it, and then make sure
> the streaming client always buffers up at least that much time before
> playback is started.  Voila - instant protection against starvation
> due to silent frames being compressed to ultra-tiny packets with a
> long delay.
>
> Some of the comments here have talked about low latency, but I would
> say that low latency has no place in an internet streaming
> broadcast.  I mean, the listened have no frame of reference for
> latency anyway, so what does it matter if the latency is really high?

You can say that but I can also stick my fingers in ears and whistle
whilst you do. 2kb of ram is enough for anyone...

> Now that I think about it this way, I'd say that FLAC and OggFLAC
> should not have any real problems due to compression of silent
> frames.  Any place there is a problem should be blamed on bad
> streaming client / player code, not on the format itself.

Its not in the format or the client / player code. Its in libflac as I
have pointed out.

-David

>
> Brian Willoughby
> Sound Consulting
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>