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