Re: Query about xrun on usb/pcm

[Takashi Iwai <tiwai@suse.de>]

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