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

[Brian Willoughby]

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