Custom i2s in with simultaneous S/PDIF & USB out

[yes2i2s]

I jumped to the design this week, I have the whole schematic pretty much complete. I've used the XMOS altium files to import the XMOS sheets and tie them to mine using sheet symbols.

All looks good so far.

However this SPDIF issue on my crude prototype worries me.

My external MCLK is actually in the 11-12MHz range (depending on the samplerate being played).

The USB side part of XMOS picks this up fine and sends the audio to my PC nice and clear, but the SPDIF output I am copying from my I2S input is scrambled and my speakers won't lock to it.

I notice that my externally inserted MCLK will land at pin 1 on the NC7SZ175 to clock the audio out.

Is there a chance that the NC7SZ175 could dislike an MCLK even though the XE216-512-TQ128 is totally happy with it?

If so what do I need to do so the XMOS and SPDIF outputs work correctly with my external MCLK and I2s audio?

Thanks!

[infiniteimprobability]

Is there a chance that the NC7SZ175 could dislike an MCLK even though the XE216-512-TQ128 is totally happy with it?

Perhaps - what does the clock look like on a scope? The D-type is directly clocked by the signal whereas the Xmos chip samples the clock input each processor clock cycle (500MHz -> 2ns).

If so what do I need to do so the XMOS and SPDIF outputs work correctly with my external MCLK and I2s audio?

What does the scope output look like? Is it what you'd expect?

OK, we know that running with 256 * 44100 (11.2896MHz) or 512 * 48000 (12.288MHz) is fine for SPDIF. The first XMOS UAC2 board sold 4 figures and used a 256x MCLK for 44100/88200. So there is something that is wrong in your system, and this needs to be debugged and found.

I don't think SPDIF is running too slowly - it would cause I2S to backup. So it's either running too jittery or too fast.

I would check:

- MCLK to the D-type is looking good. Are the edges monotonic? If not, you may be getting some double clocking
- You are sending the right clock and sample frequency values to SPDIF?

Try putting printf after

/* S/PDIF transmit thread */
void SpdifTransmit(buffered out port:32 p, chanend c_in)
{
int chanStat_L[2], chanStat_R[2];
unsigned divide;

/* Receive sample frequency over channel (in Hz) */
unsigned samFreq = inuint(c_in);

/* Receive master clock frequency over channel (in Hz) */
unsigned mclkFreq = inuint(c_in);

<PRINT out mclk and sample rate here>

If the first is dodgy, then you'll need to look at the signal integrity of the MCLK. If it's the second, then your defines in customdefines.h may be iffy...

[yes2i2s]

Thanks

I think the MCLK is not correct but somehow the XMOS proc can work with it. I am pressing on with PCB design and will debug the firmware on the MCLK source later on, as it was throwing 7MHz at one point.

[yes2i2s]

I'm ready to make this. Is this the ONLY place to get a PL611? Why such a hard to source part on the reference design? Any tested working alternatives?

https://www.arrow.com/en/products/pl611 ... technology

[infiniteimprobability]

You can use any clock source you want... A cheap way of doing it is using two separate crystals and a mux like this:

https://www.xmos.com/download/private/U ... 1.1%29.pdf

Actually you could delete the mux at the expense of an additional I/O port and a bit of software!

[yes2i2s]

Thanks

[yes2i2s]

Please help I now have my manufacturerd board from this design and so far everything has worked, brilliant. Now the final piece. The xmos chip flashes fine and the audio device appears in Windows and I can set it as default. But when I play audio, the program playing the audio just freezes. I can move the progress bar around and the software doesn't completely crash but playback does not commence.

When I take a scope to the board all the i2s lines are up and running but nothing on the digital audio date line to the DAC.

My first suspicion is that the code is full of i2c read/write commands to the cirrus DAC and ADC on the multi channel kit board. And as those chips do not exist in my design (I am not using the xmos chip for i2c control at all and using a different DAC and no ADC) maybe it's crashing and not playing audio.

So I tried commenting out all the REGREAD lines from the configuration file and rebuild but this made no difference other than throwing an error when playing in Windows rather than just not playing.

Can someone tell me how to get an audio output on the dac1 output channel without i2c being used at all, or let me know if that's not likely the cause (although I've seen this sort of behaviour before on a system with missing i2c devices as they don't respond and seem to crash the code)

I'm using the TUSBAudio driver

Thanks!

[yes2i2s]

Also when I change the output samplerate from 44k > 48k, the LRclk line on the I2s bus follows suit. So I know the driver is talking to the chip, and it's paying attention, all seems to be running, but trying to play audio freezes. This does not happen when I run the same firmware on the multi channel audio dev board.

Could this be the lack of response from the I2C chips in the reference code?

Thanks!

[yes2i2s]

I'm gathering it's very similar to the directions in this post, but I cannot be specifically sure on how to do this for the app_usb_aud_xk_216_mc project.

Any directions gratefully received! :)

Tom

[yes2i2s]

*jumps up and down*

Deleted loads more I2C code, and it works! :) :) :)