[alsa-devel] [PATCH 5/6] compress: add the core file
vinod.koul at linux.intel.com
Tue Dec 6 07:03:00 CET 2011
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
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.
More information about the Alsa-devel