dsp after dmix

dsp after dmix

[Michael Trimarchi]

Hi all,

I have written a plugin to use the dsp of omapl138 and filtering the
audio stream.
My problem is to apply filtering after dmix plugin. Is there a way to have dsp
filtering after alsa mixing?

Michael

Re: dsp after dmix

[Clemens Ladisch]

Michael Trimarchi wrote:
> My problem is to apply filtering after dmix plugin.

The dmix plugin works only on top of a "hw" device.


Regards,
Clemens

Re: dsp after dmix

[Michael Trimarchi]

Hi Clemens

On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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? (arm9 is to heavy)

Michael

>
> Regards,
> Clemens

Re: dsp after dmix

[Clemens Ladisch]

Michael Trimarchi wrote:
> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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.


Regards,
Clemens

Re: dsp after dmix

[Michael Trimarchi]

Hi

On Mon, Oct 14, 2013 at 2:15 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
> Michael Trimarchi wrote:
>> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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?

Michael



>
> Regards,
> Clemens

Re: dsp after dmix

[Clemens Ladisch]

Michael Trimarchi wrote:
> On Mon, Oct 14, 2013 at 2:15 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
>> Michael Trimarchi wrote:
>>> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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?

Yes, it would be possible to replace the dmix plugin with your dsp-mix
plugin.


Regards,
Clemens

Re: dsp after dmix

[Takashi Iwai]

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@ladisch.de> wrote:
> > Michael Trimarchi wrote:
> >> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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.


Takashi

Re: dsp after dmix

[Michael Trimarchi]

Hi

On Mon, Oct 14, 2013 at 2:27 PM, Takashi Iwai <tiwai@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@ladisch.de> wrote:
>> > Michael Trimarchi wrote:
>> >> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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?

Michael

>
> Takashi

Re: dsp after dmix

[Michael Trimarchi]

Hi

On Mon, Oct 14, 2013 at 2:33 PM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> Hi
>
> On Mon, Oct 14, 2013 at 2:27 PM, Takashi Iwai <tiwai@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@ladisch.de> wrote:
>>> > Michael Trimarchi wrote:
>>> >> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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?
>

dmix->aloop->dsp_plugin->hw

Is it possible to describe in alsarc?

Michael


> Michael
>
>>
>> Takashi

Re: 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@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@ladisch.de> wrote:
> >> > Michael Trimarchi wrote:
> >> >> On Mon, Oct 14, 2013 at 9:08 AM, Clemens Ladisch <clemens@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

Re: dsp after dmix

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 612 bytes --]

On Mon, Oct 14, 2013 at 02:18:27PM +0200, Michael Trimarchi wrote:

> > 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?

I'm not sure that's generally common - memory to memory DSPs are a bit
unusual for audio since the latency requirements tend to be fairly
tight.  I can't think of many examples that don't need some exposure to
the kernel...

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: dsp after dmix

[Michael Trimarchi]

Hi Mark

On Mon, Oct 14, 2013 at 10:33 PM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Oct 14, 2013 at 02:18:27PM +0200, Michael Trimarchi wrote:
>
>> > 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?
>
> I'm not sure that's generally common - memory to memory DSPs are a bit
> unusual for audio since the latency requirements tend to be fairly
> tight.  I can't think of many examples that don't need some exposure to
> the kernel...

A lot of time you need to deal with SDK from others so in my case the dsp
can be used only from the userspace. If the applicaiton does not do the
audio mixing and the dmix is optimized to use the mmap and shared
memory region the only way is to use somenthing like the aloop but
this will increase the overhead like using pulseaudio.

Michael