Re: Functionality of pcm_notify in snd-aloop?

[Takashi Iwai <tiwai@suse.de>]

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