Re: Correct stopping capture and playback substreams?

[Pavel Hofman <pavel.hofman@ivitera.com>]

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.

Thanks a lot,

Pavel.