On Fri, Jan 7, 2011 at 11:25 PM, Brian Willoughby <bri...@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. -David > > 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
