[alsa-devel] dsp after dmix

[Takashi Iwai]

At Mon, 14 Oct 2013 14:33:55 +0200,
Michael Trimarchi wrote:
> 
> Hi
> 
> On Mon, Oct 14, 2013 at 2:27 PM, Takashi Iwai <tiwai at suse.de> wrote:
> > At Mon, 14 Oct 2013 14:18:27 +0200,
> > Michael Trimarchi wrote:
> >>
> >> Hi
> >>
> >> On Mon, Oct 14, 2013 at 2:15 PM, Clemens Ladisch <clemens at ladisch.de> wrote:
> >> > Michael Trimarchi wrote:
> >> >> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens at ladisch.de> wrote:
> >> >>> Michael Trimarchi wrote:
> >> >>>> My problem is to apply filtering after dmix plugin.
> >> >>>
> >> >>> The dmix plugin works only on top of a "hw" device.
> >> >>
> >> >> Yes I have seen the code. Is there anyway to work with dps without passing
> >> >> thought pulseaudio?
> >> >
> >> > You would have to write an ALSA kernel driver for the DSP device.
> >> >
> >>
> >> This is not a good approach of the general problem because a lot of
> >> dsp has userspace
> >> support and firmware and initialization is done by userspace library.
> >> Can I change
> >> the writei and readi of the dmix plugin and let use my dsp function?
> >
> > It's not trivial approach, either.  The key of dmix is the mmaped
> > buffer shared among multiple clients, and the shared buffer may be
> > altered at any time by any client.  This makes the post processing
> > pretty difficult.
> >
> > If the post-processing can be applied in real time, one alternative
> > approach would be to go through loopback device.  But it's also tricky
> > and involves many round trips.
> >
> 
> Yes I know about shared area mapping. Can you explain a bit more
> the loopback device approch?

Set up the loopback device, write to it via dmix from multiple apps.
In parallel, run a user-space daemon that reads the loopback as input
and writes the processed data as the output to the real output
device.


Takashi