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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
