[alsa-devel] [PATCH 5/6] compress: add the core file

[Vinod Koul]

On Tue, 2011-12-06 at 08:30 +0530, Nallasellan, Singaravelan wrote:
> > 
> > The notion of a START threshold isn't self-explanatory for compressed data. The
> > decoder may or may not have enough data available for specific values of the
> > threshold, and the behavior would be decoder/implementation specific.
> > Besides, this was never implemented in the proprietary Intel API we've been using for
> > 2+ years and no one complained...
> 
> Even the thread which actually writes the data to ring buffer may not have the idea of frames
> So the start threshold does not require to be on frame boundaries. It is just to avoid START 
> when the buffer is written with the data. If the write gives more data than the ring buffer, 
> write will not unblock and the user space application may not be able to call START. 
> This will be an issue if you go for non-blocking implementation. Otherwise, START should
> be called in another thread than the thread which writes the data.
You are confusing kernel API to user space stuff. Please stick to kernel
API discussion here. Nevertheless above has nothing to do with threshold
question!

At the peril of repeating myself again
- You have information of "exactly" how much data is there, so why do we
need a threshold.
- START threshold as explained above doesn't fly for compressed data

In PCM we would need to know what is the least amount of data which is
available in ring buffer for lower level driver to start. In compressed
data, you know to how much data is available for you to decode at any
point of time, use that information.

-- 
~Vinod