On Mon, 30 Mar 2020 17:09:58 +0200, Jaroslav Kysela wrote: > > 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. I believe the missing piece here is a generic way to tell user-space that the stream got invalidated. This would be useful not only for aloop but can be applied in general when a stream becomes temporarily unavailable (e.g. the HDMI monitor disconnected or the DSP route switched). Currently we may return -EPIPE for xrun, but this doesn't really tell the situation correctly. The xrun should be recoverable by simple PREPARE call, but the case like aloop would need the complete re-setup or reopen of the stream. thanks, Takashi
