Can core clock or package type impact streaming timing?

[audioengr]

I have a XS1-L1 type design implemented in the 48-pin part with the same core elements. Small changes were made, like bringing out the sample-rates to pins. I use exactly the same chips and design, including the USB3318 and 13MHz clocks.

I am having data errors at the XMOS output pins on both I2S and S/PDIF at 176.4kHz and 192. 44.1-96 sample-rates work perfectly and sound great. When using I2S, I get music, but when there are louder passages, it crackles at 176.4 and 192.

Everything seems to be correct and identical to the reference board. When I play the reference board, it plays 176.4 and 192 without errors. I have tried different USB cables and powered the +5V in the USB cable from an external supply, so I don't believe its the USB cable. I am playing with TUSBAudio spy tool and so far no errors on the cables I'm using.

I have tried freeze spray on the USB3318 and the XMOS chip while playing 192 - no effect. I have changed the relative timing of the 13MHz clock at the XMOS versus the USB3318 - no effect.

I am at wits end as to what this is. It would help to know what the core clock rate and the PLL registers are in the reference board design, in case my firmware designer set these wrong...

Thanks,
Steve N.

[Ross]

Due to the volume dependancy my Initial thoughts would be that the DAC doesn't like the I2S timing, or is the wrong mode. What DAC are you using?

Could also be USB packet loss due to bad layout.

[lilltroll]

Create a thread that calculates a 64-samples long sine-wave with double's.
Then store it in a int sin[64] Array and feed it in a while loop to your I2S thread.
Skip everything else and test it at all different sample rates.

Doing so you can resolve if the problem is prior the I2S thread or later.

[audioengr]

Ross - I have a DAC that I designed and sell now for about 5 years that has I2S input using a short cable. My current M2Tech based USB converter with I2S output works fine with it at 192. It also works fine with many other companies DACs with I2s inputs, including PSAudio, Northstar, Stello, AudioGd and Buffalo. The I2S on the XMOS module works fine at all frequencies except 176.4 and 192. It's not the I2S interface on my side. It works fine up to 96kHz.

The S/PDIF output on the XMOS chip does not work right at 176.4 or 192.

I have also noticed that the USB3318 seems to be more sensitive to the USB cable quality than my current interface. a couple of cables that work fine on my current USB interface will not work with my XMOS design using the USB3318. Very short cables sound a lot better.

The groundplane and trace lengths for my design are very short. The entire module is 1/6 the size of your XS1-L1 board. It is a 4-layer board with unbroken groundplane. I dont believe
i have any signal integrity problems. to give you some perspective, I'll share some of my experience. I have been designing high-speed digital for almost 30 years. I was a design team lead on the Pentium 2 at Intel and developed their massively parallel supercomputer messaging network. I have been designed high-performance digital audio products since 2009.

I am starting to think that maybe its the USB3318 that is causing this problem.

Today I tried a number of things that might improve this, including:

1) increased the power on reset time to the 3318 and XMOS chips in case the power voltages were not stable when reset is deasserted
2) improved the noise on the +5V line to the 3318 by adding another decoupling cap and a series ferrite bead
3) Improved the XMOS PLL reference voltage noise by adding decoupling cap

None of these made any difference. No SPDIF output at 192.

I suppose it might be possible that the USB termination settings in the 3318 are not set correctly, but I cannot look at the code that programs this. I cannot imagine how my firmware designer would change these. He has apparently abandoned me BTW. Does not return my emails. I dont have the source code for any of this.....

Thanks,
Steve N.

[zohaa3492]

thats very interesting ahenshaw, i think i actually have that problem with my wifi slice and i submitted a ticket about it.

Running the demo application on the slicekit gives me this:




__________________________________________
http://www.vceexam.com/extension/download-vce-player.html
http://www.arbor.edu/
http://www.hp.com/

[bearcat]

My thoughts. Look at the I2S sync. I have seen if the I2S sync gets off by a bit or two between the clock, XMOS, or the DAC, you will get digital clipping at high sample values, which sounds awful. Also, software clipping sounds the same. Try right shifting the sample a few bits in software and see what happens, that's easy to test.

I have needed to use a logic analyzer on the I2S to debug everything on my prototypes. Just keep sending out a static value, and verify on the analyzer between all the signals. That would be my next step.

My experience with the USB3318 is good, and that's with 2 layers.

[lilltroll]

Another thing to check on your custom board PCB:

Check that I2S word-clock and data is written out on the falling flank on bit-clock.

I missed that with my logic analyser but detected that with my DSO.

In my case I do not use the Master clock. I just use the bit clock.

The default for a port used as an clock-input is to sample on rising edge.

I needed to use the

Code: Select all

/**
 * Sets a port to sample delay mode. This causes the port to sample input data
 * on the falling edge of its clock.
 * \param p The port to configure.
 * \sa set_port_no_sample_delay
 */
void set_port_sample_delay(void port p);

function to correct for that.

If you are regenerating the BCLK from MCLK this should not be an issue.