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

[David Richards]

There is a hack fix that won't break the standard. Disable constant
subframes and fixed subframes on the encoding end. 100% compatible.
Your going to be using all that bandwidth most of the time anyways,
and when it goes down temporarily, that could actually cause a problem
at the network level depending on the fancyness of your QoS and other
routing razzle dazzle.

Here is the other hack so that you don't get a logjam in the Ogg layer.

https://github.com/oneman/libflac/commit/67e13364032404ebc1837af143fdd1cd81786c3a

-David

On Fri, Jan 7, 2011 at 9:12 PM, Brian Willoughby <brianw at sounds.wa.com> wrote:
>
> On Jan 7, 2011, at 16:48, Ben Allison wrote:
>> The issue is that silent frames compress to a very small size, and
>> the Ogg
>> packeting layer can put more than one FLAC frame into a page.  So
>> if you
>> have an extended period of silence with a live or rate-limited input
>> stream, the client buffers may exhaust themselves before a new page
>> can be
>> put together and transmitted.
>
> Ah, yes, I remember reading about this.  It does seem like an
> unfortunate problem, and I would guess that both FLAC and OggFLAC
> have the same issue.  At the very least, I don't see how OggFLAC
> could compress more than FLAC when using FLAC, and thus the problem
> should be the same in both.
>
> However, if you've been following my suggestions about flagging
> silence and other gaps in the broadcast content, then I think there
> might be a common solution to both problems.  With flags for silence
> defined in the protocol, the streaming broadcast server would be able
> to alert the clients to the situation where an extended period of
> silence is about to occur.  Maybe there would even need to be some
> advance notice, otherwise the flags would come too late, just like
> the silent frames.  Seems like the streaming broadcast server could
> define some sort of maximum time gap, and if a future frame is going
> to exceed this maximum time, then a prior frame could be encoded with
> a flag announcing the imminent "problem" - upon which the client
> could simply prepare to go silent and resync.
>
> It still seems difficult, because the trailing audio right before the
> silent frames could end up getting trapped in a FLAC block that takes
> too long to arrive because it is mostly silent, but not completely
> silent.  Perhaps a "short" block is needed so that all of the non-
> silent audio can be sent right away, along with a warning flag, and
> then the client will know to produce silence (and perhaps resync)
> until the super-compressed silent frames finally arrive.
>
> Unfortunately, this all seems like a significant deviation from the
> FLAC streaming standard, unless variable block sizes can be allowed.
> I must admit that I have not studied this closely, but I do seem to
> recall that the block can is allowed to vary under certain
> conditions.  It might be the case that certain decoders only work
> with fixed block sizes, but a streaming broadcast client would
> obviously be a special case where support for small blocks could be
> mandatory without causing a huge problem.
>
> Apparently, slim has something along these lines in their stream, but
> I wonder whether they've fully taken advantage of the possibilities.
>
> Brian Willoughby
> Sound Consulting
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>