Correct stopping capture and playback substreams?

[Takashi Iwai]

On Mon, 03 Jan 2022 13:28:17 +0100,
Jaroslav Kysela wrote:
> 
> On 03. 01. 22 13:15, Takashi Iwai wrote:
> > On Mon, 03 Jan 2022 12:32:53 +0100,
> > Pavel Hofman wrote:
> >>
> >>
> >>
> >> Dne 03. 01. 22 v 10:10 Jaroslav Kysela napsal(a):
> >>> On 03. 01. 22 9:22, Pavel Hofman wrote:
> >>>>
> >>>> Dne 23. 12. 21 v 9:18 Pavel Hofman napsal(a):
> >>>>> Hi Takashi,
> >>>>>
> >>>>> I am working on stopping alsa streams of audio USB gadget when USB host
> >>>>> stops capture/playback/USB cable unplugged.
> >>>>>
> >>>>> For capture I used code from AK4114 SPDIF receiver
> >>>>> https://elixir.bootlin.com/linux/latest/source/sound/i2c/other/ak4114.c#L590:
> >>>>>
> >>>>>
> >>>>>
> >>>>> static void stop_substream(struct uac_rtd_params *prm)
> >>>>> {
> >>>>>        unsigned long _flags;
> >>>>>        struct snd_pcm_substream *substream;
> >>>>>
> >>>>>        substream = prm->ss;
> >>>>>        if (substream) {
> >>>>>            snd_pcm_stream_lock_irqsave(substream, _flags);
> >>>>>            if (snd_pcm_running(substream))
> >>>>>                // TODO - correct handling for playback substream?
> >>>>>                snd_pcm_stop(substream, SNDRV_PCM_STATE_DRAINING);
> >>>>>            snd_pcm_stream_unlock_irqrestore(substream, _flags);
> >>>>>        }
> >>>>> }
> >>>>>
> >>>>> For setup I found calling snd_pcm_stop(substream, SNDRV_PCM_STATE_SETUP)
> >>>>> (https://elixir.bootlin.com/linux/latest/source/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c#L63)
> >>>>>
> >>>>>     Or for both capture and playback using SNDRV_PCM_STATE_DISCONNECTED
> >>>>> (https://elixir.bootlin.com/linux/latest/source/sound/core/pcm.c#L1103).
> >>>>>
> >>>>> Or perhaps using snd_pcm_dev_disconnect(dev) or snd_pcm_drop(substream)?
> >>>>>
> >>>>> Please what is the recommended way?
> >>>>>
> >>>>
> >>>> Please can I ask for expert view on this issue? E.g. in SoX stopping the
> >>>> stream with SNDRV_PCM_STATE_SETUP/SNDRV_PCM_STATE_DRAINING does not stop
> >>>> the application, while with SNDRV_PCM_STATE_DISCONNECTED SoX exits with
> >>>> non-recoverable status. I am considering implementing both methods and
> >>>> letting users choose their suitable snd_pcm_stop operation (none
> >>>> (default)/SETUP-DRAINING/DISCONNECTED) for the two events (host
> >>>> playback/capture stop, cable disconnection) with a configfs param. Would
> >>>> this make sense?
> >>>
> >>> The disconnection state is unrecoverable. It's expected that the
> >>> device will be freed and cannot be reused.
> >>>
> >>> If you expect to keep the PCM device, we should probably introduce a
> >>> new function which puts the device to the SNDRV_PCM_STATE_OPEN
> >>> state. In this state, all I/O routines will return -EBADFD for the
> >>> applications, so they should close or re-initialize the PCM device
> >>> completely.
> >>>
> >>> https://elixir.bootlin.com/linux/latest/source/sound/core/pcm_native.c#L794
> >>>
> >>
> >> The fact is that after closing the USB host can re-open the device
> >> with different samplerate (and perhaps later on with different
> >> channels count/sample size). That would hint at the need to
> >> re-initialize the gadget side before opening  anyway.
> >>
> >> As of keeping the device - it's likely some use cases would prefer
> >> keeping the device, to minimize the operations needed to react to the
> >> host-side playback/capture start.
> >>
> >> A function you describe would make sense for this. IMO from the gadget
> >> POW there is no difference  between the host stopping playback/capture
> >> and cable disconnection, in both cases the data stream is stopped and
> >> next stream can have entirely different parameters. Maybe the gadget
> >> configfs parameter could only toggle between no action (i.e. current
> >> situation) and the new alsa function stopping the stream.
> >>
> >> Jaroslav, please can you draft such a function? Perhaps both changes
> >> could make it to 5.17.
> >
> > (Sorry for the delayed response, as I've been on vacation and now
> > catching up the huge pile of backlogs...)
> >
> > About the change to keep PCM OPEN state: I'm afraid that the
> > disconnection in the host side may happen at any time, and keeping the
> > state OPEN would confuse the things if the host is indeed
> > unrecoverable.
> 
> I don't think so. The SNDRV_PCM_IOCTL_HW_PARAMS must be issued by the
> application (in the PCM_OPEN state) and if the USB bus connection is
> no longer active, it may fail. We can distinguish between host ->
> device disconnection and device -> host one. It is not really a
> similar thing.

Well, I don't know whether we have a proper protocol to downgrade the
state from RUNNING to OPEN.  Currently the valid state transition
seems to be RUNNING -> SETUP, XRUN, or DISCONNECTED.  So, if any, this
might be a two-step procedure.


thanks,

Takashi