The feedback endponit doesn't work with Evaluation-Driver-for-Windows_5_72 ?

[Henry]

Hi everyone,
The device is XU316, the software is the lastest "sw_usb_audio_9_1_0", and the driver is the lastest "Evaluation-Driver-for-Windows_5_72_0"

I run a sine wave generator on my PC to generate a continue sine wave send to the XMOS usb audio.
Then I noticed a few milliseconds of random and low-probability "blank spaces" on the PORT_I2S_DAC pin, as well as codec output noise.

I further researched and found that when "g_aud_from_host_flag" was set, the latest audio sample stored in the buffer contains consecutive "0".
By wireshark tool, I didn't capture the "0 samples", but I found the there were no "feedback" data transfer over USB.
To further verify, I toggle an output pin operation on "case XUD_SetData_Select(c_aud_fb, ep_aud_fb, result)", and indeed, I didn't see the output pin be toggled.

This problem has stuck me for a few days, until today, I uninstalled the evaluation driver and switched to using Windows native drivers.
Then I found the output pin be toggled (every 1ms), and there is no "blank spaces" on the PORT_I2S_DAC pin, as well as I can see "feedback" data over USB by Wireshark.

Another case is, if I disable XMOS usb audio input channels, even with the evaluation driver, the feedback endponit works.

I suppose, with the audio input channels enabled, the evaluation driver uses the USB_CHAN_IN data size to process feedback rather than of the feedback endpoint.
But in the usb audio software, USB_CHAN_IN data size is not associated with the actual host rate, so there is actually no feedback.

Is there anybody met the same problem?
Without the host driver, my job will stuck.

Thanks in advance

[Ross]

What hardware are you running on?

[Henry]

Running on our self-designed board, using the XU316-1024-QF60B-C24 xCore chip

[lmariotti]

Hi Henry,

with same conditions (XU316, sw_usb_audio_9_1_0 and Evaluation-Driver-for-Windows_5_72_0) on a custom board I've also noticed a strange "pop noise" that happens randomly during listening sessions.
I tried two different computers, on one the problem is extremely frequent while on the other it is almost non-existent. Both are Windows 11 with same version.

Without Evaluation-Driver everything works perfectly.

[Ross]

Are you sure you have master clock wired up on both tiles?

[lmariotti]

Hi Ross,

in my case MCLK is generated by SI5351A and through an NC7NZ34 goes to X0D35 and X1D11

Now that I'm getting back into it, I remember that the USB clock in tile 0 is also shared as the MCLK of an extra I2S line as follow, I don't know if that may cause trubles

Code: Select all

clock aux_i2s_clk;
unsigned x;
asm("ldw %0, dp[p_mclk_in_usb]":"=r"(x));
asm("setclk res[%0], %1"::"r"(aux_i2s_clk), "r"(x));

uint32_t aux_i2s_mclk_bclk_ratio = (24576000 / (AUX_I2S_SAMPLE_RATE * 2 * 32));
set_clock_div(aux_i2s_clk, aux_i2s_mclk_bclk_ratio >> 1);

[Ross]

That should be just fine, running an additional clock-block from that port shouldn't have any bad side effects.

Just make sure mclk made available and running at the correct speed before AudioHwInit() or AudioHwConfig() return.

[Henry]

Are you sure you have master clock wired up on both tiles?

Hi Ross,
Yes, I just checked again.
On my board XUD run on tile1 while AudioHub run on tile0.
The MCLK connected to 1G on tile1 and 1L on tile0.
I have make some changes in XN file and xua_defs.h to make the software suit for my board.
I think the hardware connection is good, after all it can works well without the evaluation driver or with USB_CHAN_IN set to 0

[Henry]

Hi Henry,

with same conditions (XU316, sw_usb_audio_9_1_0 and Evaluation-Driver-for-Windows_5_72_0) on a custom board I've also noticed a strange "pop noise" that happens randomly during listening sessions.
I tried two different computers, on one the problem is extremely frequent while on the other it is almost non-existent. Both are Windows 11 with same version.

Without Evaluation-Driver everything works perfectly.

Hi lmariotti,
Thank you for sharing. If you have any new updates, please let us know.
I also tried on different computers, but the results were similar.

[Ross]

When the input stream is enabled thesycon does't use the feedback endpoint, it just sizes the output packets based on the input packets (called "implicit feedback").

My guess is still that the mclk isn't being read correctly and both driver mechanisms are failing in different ways- just you notice one more as it's more audible/catastrophic.

I'd check if master clock counter is ever non-zero (https://github.com/xmos/lib_xua/blob/eb ... er.xc#L602)