No simultaneous in & out USB audio with lib_xua

Discussions about USB Audio on XMOS devices
Jash
Junior Member
Posts: 6
Joined: Mon Apr 07, 2025 9:38 am

Post by Jash »

Hello,

Thank you for this new idea, I checked out the MCLK counts at each SOF period and it is approximately 3072 (3071 or 3073 from time to time), just like you said.
By the way, I use pin X0D11 as tile 0 clock input looped back from internal PLL on X1D11 (I didn't do it at first a few months ago and the USB device wasn't even recognized)

I also added some printf at ep_buffer.xc line 509 and at decouple.xc line 897 to know when an input stream is requested by host: input stream is started (in XUA_Buffer_Ep() then in XUA_Buffer_Decouple()) two times when I try to record the mic inputs.

I did the same at ep_buffer.xc line 820 and at decouple.xc line 1091 to know when the device has sent a packet to host: this is never reached (both in XUA_buffer_Ep() and XUA_Buffer_Decouple()), so the mics datas from audiohub don't reach the buffer, even if the request from host has been received.

Does it make you understand what could be happening?
User avatar
infiniteimprobability
Verified
XCore Legend
Posts: 1160
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

OK, so you have a good MCLK count, audio is looping and some configs are working. Those are all of the basics. You are also looking in all of the right places and have acquired a good depth of understanding of the firmware.

I am not sure what else to suggest other than continuing to follow signal path from audiohub->decouple (which fires an ISR and populates the device to host buffer) and then tells XUD (USB) that next time an IN on the ISO data endpoint occurs that the buffer is there.. EPBuffer just handles the enabled select case and signals back via shared mem to decouple to say it has been consumed. So I think decouple is definitely the place to look further.

The buffer (aud_to_host_buffer) consists of a length field followed by the payload. So, looking at the logic, it must be the case that decouple either thinks it's in underflow or the buffer length is 0. Is it possible to stick a print in to check which of these is causing the lack of input data transfer?


One other thing to explore - I spoke to a knowledgeable colleague and he says that Audacity can be unstable on windows when recording multi-channel. Can I ask a bit more about the host setup, and whether you have any other options to see if we can rule the host out? I use Linux and find arecord gives very good control over what exactly get requested of the device in terms of rate, channel count and format.
Engineer at XMOS
User avatar
infiniteimprobability
Verified
XCore Legend
Posts: 1160
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

Another thing to check is the value of g_aud_to_host_flag. This is initialised to 1 in EPBuffer if input is enabled.
Engineer at XMOS