[Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
rawdod at gmail.com
Fri Jan 7 20:45:03 PST 2011
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.
> Brian Willoughby
> Sound Consulting
> Flac-dev mailing list
> Flac-dev at xiph.org
More information about the Flac-dev