[Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
rawdod at gmail.com
Fri Jan 7 20:49:03 PST 2011
The actual non made up number for 44100 is 23 seconds. :D
4096 samples, 254 packets in an ogg page.
On Fri, Jan 7, 2011 at 11:44 PM, Ben Allison <benski at winamp.com> wrote:
> The main problem is in the Ogg layer, in my opinion.
> Imagine this extreme use-case with __completely made up__ numbers. This
> is a scenario where the server is encoding to FLAC on-the-fly from a raw
> PCM input, either from disk or a live stream.
> Let's say the FLAC block size is 1024 samples, or 23ms at 44100 Hz.
> Let's say each silent block compresses to 1 byte. Let's also say that the
> Ogg packeting layer wants 4096 bytes before creating a page. Again -
> these numbers are completely made up, but illustrate the point. In this
> example, it would take 95 seconds of digital silence before Ogg decided to
> send another page out over the network.
> If the input audio on the server is coming from a live-source (such as
> simulcast of an FM station) or if the disk I/O is very slow, this can be
> extremely problematic.
> Ben Allison
> Principal Software Engineer
> Nullsoft, Inc.
>> 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?
>> 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.
>> Brian Willoughby
>> Sound Consulting
>> Flac-dev mailing list
>> Flac-dev at xiph.org
> Flac-dev mailing list
> Flac-dev at xiph.org
More information about the Flac-dev