XMOS schedule for xCORE-AI USB Audio apps

[Paolomio]

Does XMOS have any schedule for adding features to the XCORE-AI (XU316) USB Audio firmware?

It seems the current release (7.3.1) is missing a number of important features. These are features already available for the XU216 version. In particular, but not limited to, it must use the internal AppPLL for sync, cannot properly sync to external sync sources, TDM doesn't seem to work properly, etc.

The Readme says: "Currently this application uses the internal Application PLL to generate fixed master clock frequencies only. Therefore syncing to any external stream is not possible..."

My needs are simple: an 8in 8out asynchronous USB2 audio interface, with either I2S or TDM I/O, and can operate as a slave to an outboard (not CS2100) PLL. This is part of a much larger system, which has numerous sync sources and low-jitter PLLs elsewhere.

If there is not an update forthcoming for the "AI" version I'll have to use an XU216 and older firmware for this solution. I'd prefer to use the most up to date silicon, since this product will be in production for many years, and respins are to be avoided if possible.

Any idea when something like this might become available?

[Joe]

"My needs are simple: an 8in 8out asynchronous USB2 audio interface, with either I2S or TDM I/O, and can operate as a slave to an outboard (not CS2100) PLL"

This is possible with the current firmware (which supports xcore.ai and xcore-200). The clock source for master clock can come from anywhere (internal appPLL, cs2100, external oscillators, etc etc.). The firmware needs control over the frequency supplied to MCLK (say 24.576 or 22.5792MHz) to select the appropriate clock for the sample frequency selected by the USB host.

"TDM doesn't seem to work properly"

Not sure what you mean by this.

Cheers,
Joe

[Ross]

To add to Joe's reply, xcore.ai is a superset of xcore-200, it that in can use its internal PLL to generate master-clock frequencies. This is an additional feature, rather than a restriction.

An up an coming release will include sync to external sources using this PLL, but this doesn't seem to be what you're asking for.

[Paolomio]

Hi Joe and Ross,

Thanks for the info. In the past I've done lots of development with XMOS parts, but not in a long time, and not with the USB stack. I farmed that out way back when.

Based on your comments, it looks like I can basically ignore the internal PLL, since I generate MCLK, BCLK, and LRCK elsewhere--assuming that I run it as an ansync slave. Is that your understanding/experience?

Re my comment about TDM, one of the readme's says "Input via TDM master unreliable due to low-level timing issues" but in looking again I see this is for xcore-200 only. I have a vague recollection of another TDM limitation, but can't find anything, so I'm probably misremembering. Ignore me on this one.

I'm not exactly sure what you mean by "The firmware needs control over the frequency supplied to MCLK (say 24.576 or 22.5792MHz) to select the appropriate clock for the sample frequency selected by the USB host." Can you elaborate?

Cheers,

Paul

[Joe]

Good stuff. Yes you can ignore the internal appPLL if you are using an external MCLK.

If you supply an external MCLK to the xmos device then the xmos device still needs a mechanism to select which master clock frequency is supplied to it. This can be as simple as a single IO to select (mux) between, say, 22.5792 and 24.576MHz. Alternatively, like on the new hardware platforms, we use i2c to communicate with an external PLL/clock generator to set the frequency that way.

This is because the USB device is usually configured to support more than one sampling frequency (e.g. 44.1 and 48kHz) and needs a different master clock for each (512*Fs = 22.5792/24.576MHz). The USB host controls when the sample frequency is changed and the xmos device needs to pass this configuration on to the source of the MCLK being supplied to it. This process still happens when using the internal appPLL just the communication of the sample frequency change is all on chip.

Cheers,
Joe

[Paolomio]

Thanks, Joe, understood.

Our system is a little more complex, so I'll probably use SPI to communicate sample rates between the various sections, but the idea is the same.