XMOS-based Asynchronous USB to I2S interface

[1audio]

Originally Posted by labjr

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.

If optical TB ever happens.

It may be semantic but there really is one clock in SPDIF, the one in the data stream. DAC's per se don't have clocks, they are a user of them. But your point is that the clock is not local. A valid comparison is that the Async USB clock originated at the master clock frequency local to the system instead of being multiplied up from the imbedded word clock in spdif. The classic problem is extracting it cleanly from spdif. The latest chips have some extraordinary efforts to do a better job of it. They don't use the data, but rather the header which is a more stable part of the stream. They have very sophisticated PLL's to lock to the imbedded word clock and reject any high frequency components to have a clean low jitter clock for the rest of the system.

In async USB the data is actually streamed from the host and the receiver (XMOS in this case) sends commands back to speed up or slow down the rate. There is a lot of async activity going on in the XMOS to make this happen. That should be isolated from the DAC as well.

I don't think Gordon has an SPDIF receiver product, he does make a USB to SPDIF converter and its very good. My point is that there are better and worse solutions, and there is not an absolute right and wrong.

[1audio]

Originally Posted by Ken Newton

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

The source was an Auraliti PK100 and the receiver chip is a crystal CS8416. The AKM seems to have less jitter. I'll plot and provide tomorrow.

[Jogi]

Lucien,

I think it is just plug&play with a normal recent Linux machine. If it does not work with a freshly installed system, then the usual Linux path has to be walked: searching the forums, trying to find out the reason and fixing it. There is a good page here:Soundkarten konfigurieren ? Wiki ? ubuntuusers.de , but unfortunately it is in German.
Main thing is to check if the system recognizes the card with

cat /proc/asound/cards

or

lsusb

If it shows up here, then setting it as default soundcard with the commands:

sudo bash
echo options snd_usb_audio index=0 >> /etc/modprobe.d/sound-cards-order
echo options snd_hda_intel index=1 >> /etc/modprobe.d/sound-cards-order
exit

Otherwise the computer uses the built in card as default with every boot and you have to set it manually every time.
This is for Mint and Ubuntu and the like. If it is not working, it is mostly because of internal conflicts in the chaotic Linux sound system, and there should be a fix for that.

Btw in no way I have a clue what I am doing ...So when I got it working, everybody can.
I would use Windows for simplicity but for me Linux sounds much better, especially with some tweaking and/or realtime kernel.
Sorry that I cannot be more helpful, for more detailed troubleshooting someone more knowledgeable should write some tutorial. But as said before, it runs fine out of the box, so there should be no reason normally.

And hard to believe that there is room for improvement, but I see that you are still in the process of optimizing design. Count me in for the MK2 version
And again thanks for offering this very professional and thought out work for the community of freaks here , and for the very humble and kind way you manage the whole thing.

all the best,

Juergen

[PET-240]

Hey Lucien,

I'm also looking to run on linux, using an Alix 2D2 and playing between Voyage MPD and looking at MPDpup(puppy Linux). Once I receive card I have to finish dac, but I will still be able to test the connection etc.
This to be a little ongoing, but by all reports this is working a treat!

Thanks again!

Drew

[Ryelands]

Originally Posted by Jogi

Lucien's board sounds much more natural, spacious and relaxing, it is spooky sometimes ... and no trace of "digital" sound, very musical ... I would say, this is the best hundred-something bucks I've spent in a long time for audio.

Agree completely - as someone wrote to me off-list, it's perhaps the DIY-audio bargain of the decade.

I promised earlier to report the results of upgrading from bus-powered to dedicated PSU with the WaveIO. Here goes.

1. My system is based on a Fit-PC2 (an industrial-quality embedded motherboard known for good USB implementation) running a USB-orientated and fairly heavily "tweaked" configuration of cMP2, an XP-based PC-audio setup that some of you may be familiar with.

The Fit uses a linear PSU which was designed especially for small, single-voltage motherboards and makes a significant difference to its sound quality. The design is described here:

Power supply design for low power PC

The USB-to-I2S converter was Doede Douma's PCM2707-based board with Tent clock, AQVOX driver and bespoke PSU. Though now obsolete, it was considered in its day to be among the best at its price point. As noted in earlier posts, it was connected to the Fit via a ADuM4160 USB isolator and DIY cable. (BTW, note that the board, driver and isolator cost rather more than a WaveIO.)

The DAC is a home-brew TDA1541A with an elderly (but IMHO rather good) Audio Synthesis I/V stage.

2. The first step was to replace DD's board with the WaveIO powered via USB using a stock USB cable but without the isolator.

The connection to the DAC was made via the on-board I2S isolator. In the light of audiodesign's report that this is probably at least as good as direct connection, that's how I plan to leave it. The reason why is discussed below.

The improvement in sound was marked and pretty much as Jogi and others have described.

3. I then made a 5-volt PSU for the WaveIO board, again using John Swenson's design (see link) though I used a slightly better voltage regulator.

If going from the PCM2707 to the Xmos chip made for a significant improvement in sound quality, it was outstripped by powering the WaveIO with a good PSU - much improved detail and extended bass without any apparent "digital" colouration.

I'd urge anyone considering running the WaveIO without a dedicated PSU (Wolfsin?) to think again. My Fit-PC2 is probably about as good as you'll get as far as low-noise USB V+ and Gnd lines go but it simply doesn't compare to the results from a decent PSU.

4. I got a small improvement by fitting a home-brew USB cable using short lengths of CAT5 cable but no screening. Note that the WaveIO works perfectly with no +5-volt line in the USB cable: I just unsoldered it and left it at that.

5. The last step was to restore the ADuM4160 isolator. Here there is a snag - I couldn't get it to work with the WaveIO even using a stock USB cable. I don't know why this is - there's nothing wrong with the isolator but the computer cannot see the WaveIO with the isolator in circuit. I repeated the test on a different computer with the same result. Any guidance would be appreciated.

In short, my take is that the WaveIO is a very fine product but that it benefits from proper implementation. Others (though not the designers of products using the things) frequently argue that asynch protocols make things such as fancy power supplies for the digital side of things unnecessary. My experience is that this is not so.

[Telstar]

Originally Posted by Ryelands

3. I then made a 5-volt PSU for the WaveIO board, again using John Swenson's design (see link) though I used a slightly better voltage regulator.

Which one?

[Jogi]

5. The last step was to restore the ADuM4160 isolator. Here there is a snag - I couldn't get it to work with the WaveIO even using a stock USB cable. I don't know why this is - there's nothing wrong with the isolator but the computer cannot see the WaveIO with the isolator in circuit. I repeated the test on a different computer with the same result.

So you encountered the same probs, which is somehow a relief, because it excludes some dumb mistake from my side. I have no idea why it doesn't work; I guess a well equipped user (scope etc) could do some measurements to isolate (sorry for that one) the problem.
I second Ryelands experience with power supply, it does make a difference.
But even bus powered I had no urgent feeling to tweak anything, even less so now with separated PS. And that is a very good sign, as I normally feel the solder itch right from the start, especially with digital stuff.
Ryeland, if possible, try a Linux system, it is even possible to run it from USB stick or create a double boot system, so you can use both. I found especially XP very mediocre, to put it mildly, even with Asio and many tweaks.

[rsdio]

Originally Posted by 1audio

The latest chips have some extraordinary efforts to do a better job of it. They don't use the data, but rather the header which is a more stable part of the stream. They have very sophisticated PLL's to lock to the imbedded word clock and reject any high frequency components to have a clean low jitter clock for the rest of the system.

There are six valid 4-bit header patterns; three start with a rising edge and three start with a falling edge. The point I was trying to make earlier is that timing-critical clock circuits are usually designed with only rising edges or only falling edges, because mixing rising and falling edges as SPDIF does involves different propagation delays for each kind, making a problem where one doesn't exist in a locally-clocked design.

In addition, the header variations are selected based on the data in the previous word. So, while you say that the latest chips don't use the data, they're still affected by the data because every header starts with a rising or falling edge based on the previous data. Thus, the clock errors (propagation delays on output) are data-dependent and there is no way around it.

I agree that SPDIF should be retired except where needed as an adaptor to old designs.

[barrows]

"In addition, the header variations are selected based on the data in the previous word. So, while you say that the latest chips don't use the data, they're still affected by the data because every header starts with a rising or falling edge based on the previous data. Thus, the clock errors (propagation delays on output) are data-dependent and there is no way around it."

I do not pretend to be a digital engineer, and certainly my understanding of such things is in no way complete, but I once had an SPDIF receiver approach explained to me which may actually decribe "a way around it". This theoretical receiver would use software to compare the header to theoretical "perfect" patterns, and then select which of the "perfect" pattern the header is representing, rather than trying to measure the leading/trailing edges directly: thus avoiding edge measuring errors, and errors in the edges.
If I understand the explanation of how the SPDIF reciever in the ESS chips works, they appear to be using an approach somewhat like what I have attempted to describe.

In any case, I prefer to avoid SPDIF when possible in favor of an async USB receiver and close coupled I2S to the DAC, rather than jump through unnecessary hoops trying to re-invent the wheel.

[rsdio]

Originally Posted by barrows

I do not pretend to be a digital engineer, and certainly my understanding of such things is in no way complete, but I once had an SPDIF receiver approach explained to me which may actually decribe "a way around it". This theoretical receiver would use software to compare the header to theoretical "perfect" patterns, and then select which of the "perfect" pattern the header is representing, rather than trying to measure the leading/trailing edges directly: thus avoiding edge measuring errors, and errors in the edges.
If I understand the explanation of how the SPDIF reciever in the ESS chips works, they appear to be using an approach somewhat like what I have attempted to describe.

Sorry, but if it were possible to reconstruct a jitter-free clock in software, then this problem would have been solved long ago. What you're describing are data techniques, and there is no challenge to figuring out which header pattern is which. The final product must be a perfect clock, and the kinds of timing errors that produce jitter are way faster than can be corrected in software. Jitter is measured in nanoseconds and picoseconds, and you can't create a clock signal in software with that level of accuracy. It's basically the wrong solution set for the problem. Keep in mind that audio samples are timed in milliseconds and microseconds, which are a couple of orders of magnitude larger than clock signal timings.

In other words, the "compare and select" process in software would take longer time than the actual timing errors that already exist in the clock.