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
