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