XMOS-based Asynchronous USB to I2S interface

[barrows]

Thanks!

The Wavecrest is a useful tool but not the best for this type of measurement. You are looking for the phase noise spectrum to get any real information. That is very closely related to the plots published in the Stereophile. The Wavecrest looks at the cycle to cycle spread of the master clock and essentially analyses its variations. It also measures across the entire hf spectrum. Its much less sensitive to low frequency variations however.

The most accepted way to measure the phase noise of the clock is using a phase locked reference clock and a double balanced mixer along with a low noise amplifier etc. into an audio spectrum analyzer. You need a really good reference clock, which can be difficult to find or really expensive. There are several tools for converting the measured phase noise into jitter. Phase noise above 2X the sample rate will not contribute to jitter in the output. There are a lot of questions about the audibility of low frequency phase noise since its contribution is attenuated by the process and peoples sensitivity to pitch modulation is well documented (from tape and disk studies) and way higher that anything from these processes.

The important thing to look for is deterministic jitter, the specific identifiable tones that come through. These can be much higher than the random jitter and may be audible at much lower levels.

While its interesting to see what jitter is in the clock its more meaningful to see what comes through to the output of the system, since this is the cumulative effects of all the jitter mechanisms upstream. ASRC's can remove some jitter problems but they will also permanently imbed others into the stream.

Demian. So considering the WaveIO's I2S output in isolation, the important info to know would be the phase noise of the masterclock signal, correct? It appears that few folks are going to be set up to measure this very precisely.

Then for an entire DAC, looking at the analog output spectrum (ala JA's Stereophile measurements) is what will be most telling about jitter artifacts which will/may affect perceived sonics?

I have never really heard a good explanation why ASRCs may be "bad", but subjectively it is my experience that I do not "like" them. Hence I run my ESS based DAC with the onboard ASRC and DPLL defeated and provide as good a masterclock signal as I can (Crystek CCHD with as clean a power supply as possible).

 

[JensH]

@ Lorien

I have followed this thread with interest for quite some time now. I have not read all the posts though, so maybe I have missed some details.

Have you considered to move the clock oscillators to the isolated output side of the circuit? I assume that you are using the IL715 isolator from NVE. If you use the IL717 + a low cost (slow) optocoupler to select the clock, I think you could feed the very clean clock from the oscillators directly to the DAC. And the XMOS chip would still get a low jitter clock (but not a super low jitter) through the "return channel" of the IL717, which I assume will be perfectly OK for that purpose. You could of course also use the IL261. Then you would not need an optocoupler.
I think something similar was hinted at in post #382, without being specific about the details.

I think that with this arrangement, you could achieve the optimum jitter level for the master clock, only limited by the clock oscillator performance. If a low jitter on the bit clock is needed it will of course be necessary to synchronize this to the master clock with a flip-flop.

If there is no supply on the output side there will of course not be a master clock either. I don't know if that could be a problem? If it starts normal operation when the clock becomes available without locking up in some way, I guess it should be OK.

I think that such a design could be quite interesting.

 

[1audio]

Demian. So considering the WaveIO's I2S output in isolation, the important info to know would be the phase noise of the masterclock signal, correct? It appears that few folks are going to be set up to measure this very precisely.

Very few indeed and the results may not translate into a real product. Connections and implementation make it all very difficult.
Also, depending on the DAC chip Master clock may not be the one that matters.

Then for an entire DAC, looking at the analog output spectrum (ala JA's Stereophile measurements) is what will be most telling about jitter artifacts which will/may affect perceived sonics?

Its marginal to point at a jitter spectrum and pronounce what will be audible. Cleaner (fewer spurs) is better, how much so is not clear.

I have never really heard a good explanation why ASRCs may be "bad", but subjectively it is my experience that I do not "like" them. Hence I run my ESS based DAC with the onboard ASRC and DPLL defeated and provide as good a masterclock signal as I can (Crystek CCHD with as clean a power supply as possible).

Personally I would not add an ASRC unless there were a need for it. In an async USB interface its redundant.

 

[audiodesign]

With some friends, I have organized a listening session to compare the 2 outputs of the XMOS module, I2S isolated and coax.

The I2S isolated, also if used with common ground, like my schematic, is much better than coax and I don't know why.

Probably the IL715 isolator clear the I2S signals or reduce the impedance.

In the future I will do the same test with other audio system.

 

[Telstar]

With some friends, I have organized a listening session to compare the 2 outputs of the XMOS module, I2S isolated and coax.

The I2S isolated, also if used with common ground, like my schematic, is much better than coax and I don't know why.

Tnx Andrea i was waiting for this test.
How do you power the waveio, the computer and the dac? The answer is there.

 

[barrows]

My understanding...

Is that most SPDIF receivers are poor perfromers at best, adding 200-300 pS of jitter. The Coax output of the WaveIO is transfomrer isolated, right? So I expect that the differences you note are down to the improvement of avoiding SPDIF. My experience has been that well implemented I2S direct to the DAC chip will outperform SPDIF every time.

 

[rsdio]

I have never really heard a good explanation why ASRCs may be "bad", but subjectively it is my experience that I do not "like" them.

I'll make an attempt to explain it.

The input to an ASRC is assumed to be standard digital audio. The exact PCM samples are encoded in the bits, while the required DAC timing is assumed to be a "perfect" clock. You really cannot assume anything but a perfect clock because there is no additional information in the bit stream to describe any other kind of clock.

Unfortunately, what ASRC does is look at the timing of the incoming bit stream, compare it to the local DAC clock, and then alter the PCM samples to fit. In most cases, this seems to be a bad way to handle things because the incoming bit stream is a bad indicator of timing, and in the case of async USB it's not any kind of indicator. What happens is that all of the bad timing of the bit stream is "printed" onto the PCM samples, which then makes it more audible, and impossible to correct.

I think that there is only one valid application for ASRC, and that's where you do not have any control over the incoming data rate and do not have the ability to PLL the DAC clock to match. In those situations, you'd end up with a pop every time the input and output clocks miss a sample or repeat a sample. The cure for this pop is ASRC to stretch or squish the incoming data so that it fits the output DAC clock.

Getting back to Async USB, there's no need for ASRC, because the DAC clock can simply be used as a control signal to throttle the PCM sample data coming from the computer. Whether it's too slow or too fast, the DAC should not click because the computer will adjust automatically, provided the USB Device firmware and Host drivers are all communicating to specifications.

To reiterate, digital audio always involves separate clock rates on the sending and receiving devices which must be reconciled. There are four ways (that I can think of) to match the clock rates.
1) Distribute Word Clock to both devices so that they use the same clock.
2) Use bidirectional communications (FireWire Audio, Async USB, etc.) to force the sending device to match its data rate to the DAC.
3) Use a PLL to force the receiving device to match its DAC clock rate to the incoming data.
4) Use ASRC to recreate the (hopefully) appropriate waveform without changing either the sending or receiving clock rates.

In my opinion, those four options are listed in decreasing order of quality. And, by the way, SPDIF cannot handle option 2 because it is a unidirectional link. Since Word Clock is a bit complicated for the average audio person outside a studio, Async USB (or equivalent) becomes the first choice. In all cases, I see ASRC as a last resort when nothing else can possibly work.

 

[1audio]

The description of the ASRC is close but not quite complete.
The ASRC has no knowledge of the actual intended rate of the incoming data. Whatever it is is assumed to be right (asynchronous). The output is the target clock. What it does is create a model for the analog signal that the input would create with a low pass function based on the input rate (and the output rate). It can interpolate and remove some short term stuff but below a certain rate of change it morphs and does not remove it any more. The interpolated audio is encoded into samples and passed to the output.

They have many uses but are a real compromise if not necessary and a really good one (like the Berkeley Audio implementation) uses a fair amount of processor.

There is also the synchronous sample rate converter which knows the input rate and the output rate and can use a more specific and optimized interpolation and filtering process. These are what are tested here: SRC Comparisons . The tests will give some insights into the challenges, and those are running on high powered PC's and don't need to deal with odd sample rates.

 

[rsdio]

The ASRC has no knowledge of the actual intended rate of the incoming data. Whatever it is is assumed to be right (asynchronous).

As I tried to point out, the ASRC can make one assumption: That the actual intended rate of the incoming data is supposed to be aligned to a "perfect" or ideal clock - in other words, I don't think it's possible to assume that the incoming data has correctable jitter, because there is no communication channel available to describe any such jitter in a way that would allow it to be corrected. Therefore, the only logical remaining options are that the clock is perfect, or that it has uncorrectable jitter. Either way, jitter is not going to be corrected or improved.

You are correct, of course, that the incoming data's nominal rate, ignoring jitter, is completely unknown by the ASRC. No matter how long the ASRC monitors the input, there is no guarantee that future samples will arrive at the average rate seen so far.

 

[Telstar]

Is that most SPDIF receivers are poor perfromers at best, adding 200-300 pS of jitter. The Coax output of the WaveIO is transfomrer isolated, right? So I expect that the differences you note are down to the improvement of avoiding SPDIF. My experience has been that well implemented I2S direct to the DAC chip will outperform SPDIF every time.

He compared i2s outputs only, one is i2s with mini-coax connectors (see picture of the board) and the other is i2s with pins isolated with a nve chip, which is a GMR. It's not known how much jitter this isolator adds.

It is obvious that spdfi would be inferior.

 

[1audio]

Is that most SPDIF receivers are poor perfromers at best, adding 200-300 pS of jitter. The Coax output of the WaveIO is transfomrer isolated, right? So I expect that the differences you note are down to the improvement of avoiding SPDIF. My experience has been that well implemented I2S direct to the DAC chip will outperform SPDIF every time.

Not always. SPDIF can have vanishingly low jitter. Here is a plot (similar to Stereophile) of a $25 DAC from e-bay Assembled DAC 2496 (AK4396) CS8416 DAC Board 24BIT 192K | eBay that has about 10 pS of jitter at 180 Hz (if my arithmetic is right). I modded it with an input transformer and more supply filtering. It still needs some more obviously. .

There are other examples of better dacs with less jitter using conventional SPDIF interfaces. And a decent spdif interface will have pretty good isolation.

 

[labjr]

The problem with SPDIF is aligning two clocks. I can't see why anyone would use SPDIF unless there was no alternative.

 

[1audio]

The problem with SPDIF is aligning two clocks. I can't see why anyone would use SPDIF unless there was no alternative.

I think that's a little naive. SPDIF really has one clock and very sophisticated schemes have been developed to extract the clock cleanly from a data stream. I think execution is more important than core technology.

Async USB brings a number of potential benefits, but it has challenges as well and isolation on USB is a real bitch. Also the USB clock doesn't line up well with 44.1 based clocks (two clocks in USB as well).

For clock isolation transformers are much lower jitter than opto or other isolators. Use a D-latch to resync the data, word clock and bit clock. Use the back side of the master clock going into the DAC chip so everything has settled before the chip samples the data.

 

[rsdio]

SPDIF really has one clock and very sophisticated schemes have been developed to extract the clock cleanly from a data stream.

SPDIF has one clock if you're happy settling for a 'push' technology. According to Dan Lavry, an external clock will never be superior to a properly-designed internal clock, and the only logical conclusion from there is that 'pull' technology is the better choice for jitter-free clocking. Thus, you really have two clock - one at the media source and one at the DAC. The problem is that 'pull' requires two-way communication, and SPDIF does not offer that unless combined with additional technology (even if it's just another SPDIF link back to the media source).

I think execution is more important than core technology.

That's easy to say, but the challenge is that SPDIF uses both rising and falling edges for clock, and yet no digital clock technology has identical rising and falling specifications. Thus, jitter is different for rising and falling edges, and it's data-dependent.

Async USB brings a number of potential benefits, but it has challenges as well and isolation on USB is a real bitch. Also the USB clock doesn't line up well with 44.1 based clocks (two clocks in USB as well).

That's completely irrelevant. It's perfectly workable for USB packets to carry a different number of audio samples per frame. The async nature of the link means that even irrational ratios between various clocks in the system are not a problem.

I would also suggest that every DAC involves similar challenges of linking the digital and analog sides of the conversion without allowing digital noise in the analog outputs. USB should not really make this any worse unless shortcuts are taken.

 

[Ken Newton]

Not always. SPDIF can have vanishingly low jitter. Here is a plot (similar to Stereophile) of a $25 DAC from e-bay Assembled DAC 2496 (AK4396) CS8416 DAC Board 24BIT 192K | eBay that has about 10 pS of jitter at 180 Hz (if my arithmetic is right). I modded it with an input transformer and more supply filtering. It still needs some more obviously. .

There are other examples of better dacs with less jitter using conventional SPDIF interfaces. And a decent spdif interface will have pretty good isolation.

What was the S/PDIF source/transmitter used to make that plot?

 

[labjr]

I think that's a little naive. SPDIF really has one clock and very sophisticated schemes have been developed to extract the clock cleanly from a data stream. I think execution is more important than core technology.

Async USB brings a number of potential benefits, but it has challenges as well and isolation on USB is a real bitch. Also the USB clock doesn't line up well with 44.1 based clocks (two clocks in USB as well).

For clock isolation transformers are much lower jitter than opto or other isolators. Use a D-latch to resync the data, word clock and bit clock. Use the back side of the master clock going into the DAC chip so everything has settled before the chip samples the data.

The DAC clock has to be aligned with SPDIF clock so technically there is two clocks in the system which have to be synchronized. And that's the problem. You can't slow or speed up the data flow. SPDIF needs to be retired for good

With Async USB there is no clock. It's just packets of data until it is clocked out of the USB receiver using a precision oscillator in the DAC. Simple and it works well. Wavelength does both Async and SPDIF converters and Gordon Rankin will tell you the same thing.

BTW Optical Thunderbolt cables may solve isolation problems.

 

[Jogi]

O.K., finally I had time to figure out how to get the WAveIO working. Trying to set up voyage I managed to destroy my Linux OS, had to set it up again twice and ended up with the new Linux Mint 13 with Liquorix Kernel. Seems that with older Linux OS the XMOS chip is not recognized, at least in my case.
I use the SPDIF connection to a AD1865 dac with C3g/Lundahl LL1660 output stage; I tried both the isolated and non isolated output, the non isolated does not work somehow. A little PCB with the AKM4396 chip is in the drawer already for experiments with I2s.

But I am not in a hurry, because this combination already sound really fabulous! Before I used a heavily tweaked Teralink, and it is no contest comparing the two.
Luciens board sounds much more natural, spacious and relaxing, it is spooky sometimes...and no trace of "digital" sound, vey musical. Even the PRAT thing is there, and very clear positioning and lots of details without sounding "detailed".
I would say, this is the best hundredsomething bucks I've spent in a long time for audio.
First I tried to run it with external power via a Salas Shunt, but it ran out of steam. This board is really power hungry, I didn't have a heatsink big enough to get more juice out of the reg. I took a normal linear supply with 2A then, and it gets really hot.
I also tried a ADUM isolator, but it was not recognized by the computer using this. Maybe it is also some power issues, have to find the reason for this.
Again big thank you for Lucien, from a happy camper...

 

[shoom]

''Luciens board sounds much more natural, spacious and relaxing, it is spooky sometimes...and no trace of "digital" sound, vey musical. Even the PRAT thing is there, and very clear positioning and lots of details without sounding "detailed".
I would say, this is the best hundredsomething bucks I've spent in a long time for audio''.

I totally agree with the above.
Sounding pretty wonderful with my Buffalo3
A real bargain
Thanks again Lucien

 

[bigpandahk]

Dear Lorien

You got PM, I want to purchase a WaveIO board.

Thanks

 

[Lorien]

@ bigpandahk: you have PM, thank you!

@ Jogi: it's nice to see that it end up well in the end Could you share your experience with WaveIO and Linux on PM or using this thread and draw a path for other guys in using them together? The point is that I'm willing to make some sort of user manual for this card and now I'm gathering all kinds of infos related to using WaveIO with OSes other than Windows - the one that I'm used with. Any help here from any of you guys will be really appreciated!

@ JensH: I am considering the path of moving oscillators to the isolated side for some quite time now but what keeps me still is the fact that I want this change to be available for all users (including those that already own a WaveIO). It's some sort of "must be" and I'll not give it up unless I have no other choices. Well, for now it proves to be challenging for me as long as the moods required to accomplish this task are not easy to be made by end user without proper equipment and some soldering skills but I'll continue to dig in...

Kind regards,
L