Functionality of pcm_notify in snd-aloop?
Jaroslav Kysela
perex at perex.cz
Mon Mar 30 17:09:58 CEST 2020
Dne 30. 03. 20 v 16:43 Pavel Hofman napsal(a):
>
> Dne 26. 03. 20 v 18:59 Pavel Hofman napsal(a):
>> Dne 26. 03. 20 v 18:44 Jaroslav Kysela napsal(a):
>>> Dne 26. 03. 20 v 18:19 Pavel Hofman napsal(a):
>>>> Hi,
>>>>
>>>> Please how is the module params pcm_notify supposed to be used, to do
>>>> what the documentation says: Break capture when PCM format/rate/channels
>>>> changes?
>>>>
>>>> Breaking capture side operation when the playback side changes the
>>>> params is very useful, but I cannot find a way to use this param
>>>> properly. When the capture side is open, the playback side cannot use a
>>>> different parameter than the one currently used by the capture side (the
>>>> configuration space is limited)
>>>
>>> Really? Then it's a bug introduced by the last changes.
>>>
>>> If you look to sources:
>>>
>>> if (get_notify(dpcm))
>>> runtime->hw = loopback_pcm_hardware;
>>> else
>>> runtime->hw = cable->hw;
>>>
>>> And:
>>>
>>> if (!(cable->valid & ~(1 << substream->stream)) ||
>>> (get_setup(dpcm)->notify &&
>>> substream->stream == SNDRV_PCM_STREAM_PLAYBACK))
>>> params_change(substream);
>>>
>>> So the functionality should be there.
>>
>> I am using older kernels (4.15 and 3.16), but this is an old functionality.
>>
>> modprobe snd-aloop pcm_substreams=1 pcm_notify=1,1
>>
>
> Please is there any way to solve this issue? Thanks a lot for your patience.
I can reproduce this. It appears that the driver should be fixed, but I don't
have a solution at the moment.
It seems that 898dfe4687f460ba337a01c11549f87269a13fa2 from Takashi broke this
functionality (tied the cable parameters more strictly, so the playback cannot
set freely own parameters for the pcm_notify=1 case). We need to find another
way to detach capture stream in this case.
Jaroslav
--
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
More information about the Alsa-devel
mailing list