Hi all,
I wonder if anybody has any clues/suggestions about problem I'm seeing with an XMOS-based USB sound card.
As far as I can see, the card has endpoint 0x82 set up for capture data, 0x2 for playback data, and 0x82 is also used as the sync endpoint for playback. I'm assuming that's a fairly common arrangement?
I am testing it using simultaneous playback and capture, and simulating a high-CPU-load case by sleeping for long enough to cause a lot of xruns. After some random time, I see a failure case that I'm struggling to explain. It goes like this:
There's an XRUN on the playback PCM, so __snd_pcm_xrun happens, then stop_endpoints() happens, and: it decides not to stop 0x82 because its running is > 1 it stops 0x2, so its state goes to EP_STATE_STOPPING
Then the ALSA userspace code calls prepare on the playback PCM to get it going again.
This ends up in wait_clear_urbs(), which does nothing with 0x82 as it is still running.
At this point, the prepare thread is interrupted by an XRUN on the capture PCM. With this PCM, there is no sync endpoint, and 0x82 is the data endpoint. In the xrun handler: stop_urbs() sets 0x82 to EP_STATE_STOPPING. ... and the xrun handler finishes.
Then we end up back in the prepare for the playback PCM. wait_clear_urbs() then sets 0x2 to STOPPED, and the prepare is finished.
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?
I'm more than happy to clarify anything I can, or provide more debugging information.
Thanks in advance! Best, Carl