Re: [alsa-devel] [PATCH 5/6] compress: add the core file
A general note: it's not necessarily to split playback and capture devices. For example, rawmidi has a single device for full-duplex. In the case of PCM, we had to split them because of mmap. The mmap for the capture was supposed not to be read-only, some apps may want to add mark on the buffer.
Beats me why an app would want to write anything into the capture ring buffer. Do you have an example of this use case? Maybe there's a similar need for compressed data. Thanks! -Pierre
There was a requirement to add the timestamp at the beginning of each block or frame if the encoded data is in RAW format. If the encoder does add the timestamp or marker, then we don't need the write option.
On Thu, 2011-12-01 at 18:58 +0530, Nallasellan, Singaravelan wrote:
A general note: it's not necessarily to split playback and capture devices. For example, rawmidi has a single device for full-duplex. In the case of PCM, we had to split them because of mmap. The mmap for the capture was supposed not to be read-only, some apps may want to add mark on the buffer.
Beats me why an app would want to write anything into the capture ring buffer. Do you have an example of this use case? Maybe there's a similar need for compressed data. Thanks! -Pierre
There was a requirement to add the timestamp at the beginning of each block or frame if the encoded data is in RAW format. If the encoder does add the timestamp or marker, then we don't need the write option.
Who needs this information, or where is this requirement coming from. If you already get raw encoded data on frame basis, apps can take that data with current timestamp...
There was a requirement to add the timestamp at the beginning of each block or frame if the encoded data is in RAW format. If the encoder does add the timestamp or marker, then we don't need the write option.
Who needs this information, or where is this requirement coming from. If you already get raw encoded data on frame basis, apps can take that data with current timestamp...
This was requested for encoded capture for one of the voice codecs couple of years back.
-- ~Vinod
On Fri, 2011-12-02 at 15:47 +0530, Nallasellan, Singaravelan wrote:
There was a requirement to add the timestamp at the beginning of each block or frame if the encoded data is in RAW format. If the encoder does add the timestamp or marker, then we don't need the write option.
Who needs this information, or where is this requirement coming from. If you already get raw encoded data on frame basis, apps can take that data with current timestamp...
This was requested for encoded capture for one of the voice codecs couple of years back.
Why should this API care? These kind of specfic stuff should be handled in user space
participants (2)
-
Nallasellan, Singaravelan -
Vinod Koul