768 kHz usb to i2s output issue

[kubaG]

Hi,

I'm having trouble getting support for values above 384 kHz in my USB to I2S application. I'm mostly using the AN00246_xua_example from the XUA library. Here are the obvious settings I've configured:

Code: Select all

#define MAX_FREQ 768000
#define MCLK_441 (1024 * 44100) 
#define MCLK_48  (1024 * 48000)
#define I2S_CHANS_DAC 2
#define NUM_USB_CHAN_OUT 2

My application can dynamically switch between MCLK clock sources (SW / CS2100 / Si5351), but the problem occurs with each MCLK source. MCLK value generated by SW/CS2100/Si5351 is set to 1024 * 48000 / 1024 * 44100.
The first error I encountered is in lib_xua/lib_xua/src/core/audiohub/xua_audiohub.xc:734:

Code: Select all

xassert((!divider_is_odd) && "Error: divider is odd, clockblock cannot produce desired BCLK");

The issue arises because the assert catches that the divider isn't even, as it results in 1 for 768. I worked around this by commenting it out, which stops the app from crashing, but it still doesn't work properly and stable on both a PC running Windows 11 and a Linux PC. I know that Windows natively supports a maximum of 384 kHz, but I thought ASIO4ALL would solve this problem.

Should I check something else in the code, or could the issue be more related to driver/OS support on the PC side?

[Ross]

Agree, that check is too strict and needs to allow for the special = 1 case. We'll fix that. The asserts shouldn't be firing unless you've enabled them though...

786 kHz is beyond any testing XMOS does and beyond any hardware we have available. However, I should expect it to operate for stereo output.

I've tried 786 kHz streaming previously from my Mac and it seemed fine, the clocks and data looked solid on the scope, couldn't listen to it due to lack of HW (XK-AUDIO-316-MC tops out at 384 kHz)

[kubaG]

Yeah i've been able to play 768 kHz using:

• slightly modified sw_usb_audio 8.1.0

• XK-AUDIO-316-MC

• syscon demo driver + foobar2000 player + asio4all / asio4all plugin

and everything worked stable, I2S line looked fine for me.

Unfortunately on my custom hardware where i use lib_xud/lib_xua, and firmware is based on much simpler example (AN00246: Simple USB Audio Device), when i am setting #define MAX_FREQ 768000
even slower frequencies are unstable to use. Sometimes device falls into a loop of disconnecting and connecting to PC, sometimes is just stop showing up after connecting via usb as usb device.
I will probably have to check my code one more time.

[Ross]

One difference will be the “mixer” thread will be enabled in the main app. This will off load some pressure on the buffering (extra decoupling) and also does the volume processing further reducing load on the buffering subsystem.

It does sound like something more fundamental is wrong though.

[kubaG]

I double-checked the hardware as well. Somehow, the X0D11 and X1D11 pins were not connected together; X0D11 was floating as a test point...
After soldering them together, everything started to work okay, including 768 kHz!

By the way, I now remember that the reference schematic for the XK-AUDIO-316-MC in the file XCORE_AI-Multichannel-Audio-Platform-1V1-Hardware-Manual(1V1).pdf, page 22, figure 23, has this net MCLK_X_PIN that was easy to miss during moving to custom hardware.

[Ross]

Ah okay, so you had streaming issues at all rates, not just 768! This lack of MCLK connection will be pretty catastrophic.

Glad it's working now though!

[kubaG]

Also, I discovered the lack of a VBUS detect pin on my custom hardware (using galv isolation also complicated traces a little bit), so that's another difference compared to the XK-AUDIO-316-MC.
I think that it can also make some problems during reconnecting device.

[MaximLiadov]

Also, I discovered the lack of a VBUS detect pin on my custom hardware (using galv isolation also complicated traces a little bit), so that's another difference compared to the XK-AUDIO-316-MC.
I think that it can also make some problems during reconnecting device.

I know XMOS says VBUS is a must. But in my experience VBUS is not really needed for normal operation. I personally removed this requirement from the source code, and since then everything works fine. No complaints from customers.