Hi Takashi, Thank you for getting back to me! On Tue, 22 Nov 2022, Takashi Iwai wrote: [snip] > > Now, snd_usb_endpoint_start() is called on 0x2 and that is fine. Next, > > snd_usb_endpoint_start() is called on 0x82 and that fails because its > > state is still STOPPING. > > > > At this point things seem broken. > > > > Does anyone have a hint about where in this sequence things are going > > wrong, and maybe even why? > > The problem is that it's treating XRUNs on the both streams > individually. It's correct to recover only the PCM stream when an > XRUN is reported to the PCM stream. However, for an XRUN on the > capture stream that serves as a sync source, it should stop and > recover not only the capture PCM stream but also the playback stream > as a sync sink as well. > > Below is a possible test fix (totally untested!). > This may give XRUNs twice eventually, which is a bit confusing, but it > aligns with the actual hardware behavior, at least. [snip fix] Makes sense, thank you! Sadly, the fix doesn't seem to work because (I think) the xruns I'm seeing come via a different path (not though notify_xrun()). Mine arrive via this trace: __snd_pcm_xrun snd_pcm_update_state snd_pcm_update_hw_ptr usb_hcd_giveback_urb snd_pcm_period_elapsed_under_stream_lock snd_pcm_period_elapsed retire_capture_urb snd_complete_urb I'll see if can apply a similar fix to this case, though to my naive eyes it looks a little trickier as the xrun is found in the snd_pcm code rather than the USB code. Any suggestions most welcome! Kind regards, Carl
