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

David Richards 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.

-David

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
>> http://lists.xiph.org/mailman/listinfo/flac-dev
>>
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>


More information about the Flac-dev mailing list