[alsa-devel] dsp after dmix
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
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
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
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
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
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
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
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
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
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...
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
participants (4)
-
Clemens Ladisch -
Mark Brown -
Michael Trimarchi -
Takashi Iwai