On Thu, Apr 29, 2010 at 05:46:26PM +0800, Yu Hang wrote:
On 4/29/2010 5:19 PM, Mark Brown wrote:
You need to ensure that the user configures the plugin stack appropriately to ensure that your plugin is the last one that's run, you can't do this purely from within your plugin. Even if that's done you'd also need to rely on them not configuring any DSP in the hardware which would disrupt things.
From the pcm_dmix.c, dmix plugin must be followed by HW plugin. Which means I cannot insert my own plugin below dmix. Unless I patch pcm_dmix.c, I cannot retrieve the final data. Or I can patch pcm_hw.c in order to achieve my goal.
Well, you can't assume people are using dmix at all - most modern desktop systems use PulseAudio, and it's also getting more and more usage on embedded systems.
Even if I patch pcm_hw.c, how can I know when the data is actually sent to HW?
The information the driver gives you about where it's up to in the buffer and the latency will tell you this - PulseAudio is probably the most detailed example out there of this. Note that "actually sent to HW" can cover a multitude of things. There's the data that software can change, but there's also the potential for additional latency in buffers and DSP functionality before the audio that's actually being played.
I have totally no idea about ALSA driver mechanism. A biggest question is, how alsa lib (in user space) knows the HW needs new data (it must happen by interrupt) and feed HW with new data.
Most ALSA drivers continually process data from a ring buffer, with their progress through the ring buffer being updated either from interrupts generated by hardware or by polling from a timer. The driver tells userspace what region in the buffer is currently available for writing, and userspace tells the driver how much data has actually been written.