flac dev - Jan 2011 - Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

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
>

Well, in that light, I suppose it isn't reasonable to expect people  
to wait 23 seconds for their internet streaming broadcast to start  
playing.

Then again, maybe it could be sold as the "price" for lossless  
streaming!  ;-)

Seriously, though, what about if the Ogg page is not part of the  
picture?  i.e., what about just using pure FLAC and IP?

Brian Willoughby
Sound Consulting


On Jan 7, 2011, at 20:49, David Richards wrote:
> The actual non made up number for 44100 is 23 seconds. :D
>
> 4096 samples, 254 packets in an ogg page.

Give it a go, I await your results :D

On Sat, Jan 8, 2011 at 12:20 AM, Brian Willoughby <brianw at
sounds.wa.com> wrote:
> Well, in that light, I suppose it isn't reasonable to expect people to
wait
> 23 seconds for their internet streaming broadcast to start playing.
>
> Then again, maybe it could be sold as the "price" for lossless
streaming!
> ?;-)
>
> Seriously, though, what about if the Ogg page is not part of the picture?
> ?i.e., what about just using pure FLAC and IP?
>
> Brian Willoughby
> Sound Consulting
>
>
> On Jan 7, 2011, at 20:49, David Richards wrote:
>>
>> The actual non made up number for 44100 is 23 seconds. :D
>>
>> 4096 samples, 254 packets in an ogg page.
>
>
>