Query about xrun on usb/pcm
Takashi Iwai
tiwai at suse.de
Mon Dec 5 13:33:56 CET 2022
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
More information about the Alsa-devel
mailing list