* Loopback device respond to changing parameters on the other end.
@ 2020-10-05 2:38 alsa
2020-10-05 7:12 ` Pavel Hofman
0 siblings, 1 reply; 3+ messages in thread
From: alsa @ 2020-10-05 2:38 UTC (permalink / raw
To: alsa-devel
Hello,
Let me open by saying I am not an experienced ALSA developer so
hopefully I'm just missing something really easy here.
I'm trying to use some DSP programs that insert themselves into the
audio chain via the ALSA loopback device. My understanding is that
whichever program opens the loopback device first sets the parameters,
so the DSP
program has to know what parameters any playback program is going to use
before it opens its end of the loopback device. And it has to know when
to release the loopback device so that another (or the same) playback
program can open the loopback device with possibly different parameters.
(The DSP program also needs to the know the audio parameters just to
do the right thing of course.)
I'm not sure how best to accomplish this. I don't want any form of
auto-format conversion such as using a resampling or format conversion
plugin. I want the DSP program to access the raw PCM stream however it
was configured by the playback program.
I was thinking I could use the PCM hook system to accomplish what I
want. Capture the SND_PCM_HOOK_TYPE_CLOSE (and possibly even use the
hook init) to tell the DSP program to close its end of the loopback
device. Capture the SND_PCM_HOOK_TYPE_HW_PARAMS to configure the DSP
program with the appropriate parameters and tell it to open the loopback
device with those new parameters.
The init/close part is easy, but I can't figure out how to access the
hw_params about to take effect from inside the hook function. If I'm
understanding the code correctly the hook function is called from
_snd_pcm_hw_params_internal before the PCM interface is actually setup.
And snd_pcm_hooks_hw_params chooses not to pass the snd_pcm_hw_params_t
structure to the hook function itself, only the snd_pcm_t handle. But
since the snd_pcm_t hasn't actually been configured I don't see how to
get the new hw_params from it. The hook system does set the new
hw_params on the pcm private_data/generic slave device, but I'm not sure
how to access that from just libasound2. (Meaning without the full
alsa_lib set of includes that define _snd_pcm and such.)
I really hoping one can access snd_pcm_hw_params_t inside the hook
function. It seems the information really should be there given the
callback is triggered by a change to those parameters.
Alternatively, is there a better way to automatically
configure the read end of the loopback device to match the parameters of
the write end? (One that doesn't required modifying every playback
program to announce their intentions to the DSP program.)
Thanks,
scripple
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Loopback device respond to changing parameters on the other end.
2020-10-05 2:38 Loopback device respond to changing parameters on the other end alsa
@ 2020-10-05 7:12 ` Pavel Hofman
2020-10-05 15:21 ` alsa
0 siblings, 1 reply; 3+ messages in thread
From: Pavel Hofman @ 2020-10-05 7:12 UTC (permalink / raw
To: alsa, alsa-devel
Dne 05. 10. 20 v 4:38 alsa@scripple.org napsal(a):
> Hello,
>
> Let me open by saying I am not an experienced ALSA developer so
> hopefully I'm just missing something really easy here.
>
> I'm trying to use some DSP programs that insert themselves into the
> audio chain via the ALSA loopback device. My understanding is that
> whichever program opens the loopback device first sets the parameters,
> so the DSP
> program has to know what parameters any playback program is going to use
> before it opens its end of the loopback device. And it has to know when
> to release the loopback device so that another (or the same) playback
> program can open the loopback device with possibly different parameters.
> (The DSP program also needs to the know the audio parameters just to
> do the right thing of course.)
>
> I'm not sure how best to accomplish this. I don't want any form of
> auto-format conversion such as using a resampling or format conversion
> plugin. I want the DSP program to access the raw PCM stream however it
> was configured by the playback program.
>
> I was thinking I could use the PCM hook system to accomplish what I
> want. Capture the SND_PCM_HOOK_TYPE_CLOSE (and possibly even use the
> hook init) to tell the DSP program to close its end of the loopback
> device. Capture the SND_PCM_HOOK_TYPE_HW_PARAMS to configure the DSP
> program with the appropriate parameters and tell it to open the loopback
> device with those new parameters.
>
There used to be a notification module parameter (pcm_notify) which
closed the other loopback side if params changed
https://mailman.alsa-project.org/pipermail/alsa-devel/2020-March/165454.html
I am afraid it remains to be fixed.
Best regards,
Pavel.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Loopback device respond to changing parameters on the other end.
2020-10-05 7:12 ` Pavel Hofman
@ 2020-10-05 15:21 ` alsa
0 siblings, 0 replies; 3+ messages in thread
From: alsa @ 2020-10-05 15:21 UTC (permalink / raw
To: Pavel Hofman, alsa-devel
On 10/5/20 12:12 AM, Pavel Hofman wrote:> There used to be a
notification module parameter (pcm_notify) which
> closed the other loopback side if params changed
> https://mailman.alsa-project.org/pipermail/alsa-devel/2020-March/165454.html
>
>
> I am afraid it remains to be fixed.
Thanks for the info. That does seem to be what should be the solution.
It doesn't seem to be being worked though.
I'd still like to know if there's a way to get the new hw_params inside
the hw_params modify hook. Certainly that seems like information that
should be available in the call back.
scripple
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-10-05 15:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-10-05 2:38 Loopback device respond to changing parameters on the other end alsa
2020-10-05 7:12 ` Pavel Hofman
2020-10-05 15:21 ` alsa
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.