Re: [alsa-devel] [PATCH 5/6] compress: add the core file
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.
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.
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!
I don’t think you understood my point. It is the kernel implementation which impacts the user space Implementation.
-- ~Vinod
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.
I did not understand a single line of this comment. Why is this start threshold needed again and how would its value be defined for compressed data? -Pierre
participants (3)
-
Nallasellan, Singaravelan -
Pierre-Louis Bossart -
Vinod Koul