On Mon, 05 Dec 2022 12:59:54 +0100, Carl Hetherington wrote: > > Hi Takashi, > > > > Can you see any problems with that? In the application code I do need > > > to re-try the snd_pcm_prepare() if one fails with -EPIPE, but with this > > > undo step the second snd_pcm_prepare() is able to recover the endpoint > > > states, instead of hitting this problem where it tries to start things > > > that are STOPPING, but also won't set things to STOPPED because > > > stop_operating is false. > > > > Setting the stop_operating unconditionally there doesn't look right, > > as there may be other error types not only the pending XRUN. > > > > The problem is rather specific to USB audio driver that tries to start > > the stream at PCM prepare, so it's better to handle in USB audio > > driver itself. That is, when -EPIPE is returned from > > start_endpoints() at prepare, the driver does some action. > > > > I can see two options: > > - Issue snd_pcm_stop_xrun() when start_endpoints() returns -EPIPE > > - Repeat the prepare after the sync at snd_usb_pcm_prepare() > > > > The former would require a bit of change in snd_pcm_stop_xrun(), and > > it relies on the application retrying the prepare. The latter would > > be more self-contained. I attached two patches (totally untested) for > > both scenarios. > > > > My gut feeling is for the latter solution, but this needs > > verification. > > The latter solution seems to fix our problem perfectly! Thank you so > much! > > Is there anything I can/should do to help get the change merged? I'm going to submit fix patches and put you to Cc. I believe that the former patches are also valid, although it doesn't influence in your case, so they'll be included. The fixes will be likely included in 6.2-rc1. thanks, Takashi
