XMOS-based Asynchronous USB to I2S interface

Member
Joined 2004
Paid Member
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.
 
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
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 :p...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 :D
And again thanks for offering this very professional and thought out work for the community of freaks here :grouphug: , and for the very humble and kind way you manage the whole thing.

all the best,

Juergen
 
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
 
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.
 
Last edited:
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:rolleyes:, 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.
 
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.
 
maybe...

"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.
 
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.
 
The...

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.

Approach I am trying to describe was proposed to be used in conjunction with a truly asynchronous buffer, where the samples would be clocked out with a fixed oscillator, and no PLL(s) necessary... Unfortunately, I am clearly not adequately describing this approach...
 
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.

I'm very interested in this thing. I'm waiting for a ADuM4160 isolator to be delivered and this incompatibility could be a problem, if confirmed. Is there anyone who have used ADuM4160+WaveIO successfully?
 
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.

I am running Windows 7/Foobar2000 with good results on a Tranquil PC T2E (Intel D510 dual core 1.6 GHz Atom); have just received my WaveIO and would like to try a Linux 'transport' driving it out to S/PDIF being my only choice with my Chord DAC64 MkII. Whilst I am proficient at getting around in Windows, Linux pretty much stops me in my tracks.
Are there any 'plug & play' Linux transport systems that one could boot from USB stick without the need for difficult and off-putting configuration? I just want to try it to see if it is materially better SQ than my tweaked WIndows 7 and Foobar2000.

Many thanks for any advice

Jonathan
 
Jonathan...

What you will want to do is use voyage/mpd on linux for playback. This gives really great sound quality, and should be entirely compatible with the WaveIO.
Unfortunately, it is not "plug and play" easy, and if you are not fairly competant with computers, you may need some help setting it up. Do you have any local friends who are used to working with linux?
There are very detailed threads on voyage/mpd set up at the Audio Circle and Computer Audiophile forums. While set up can be tricky (I had a friend do mine, as I am not great with computers), it will be worth the effort for the sound quality which is possible, I highly recommend making the effort.
 
Lorien...

Great to hear that you are considering putting the oscillators on the outside of the isolators for a "mk II" WaveIO project. I think this is a great idea, and will remove one small "compromise" in the current design. I would suggest that feeding the masterclock back to the XMOS side would best be done via a transformer rather than through an gmr or opto type device (according to Demian's words here).
Then perhaps you could provide a separate power supply input (which could be optional) for the oscillator power supply alone. Perhaps the oscillators could be mounted on a small daughter board to allow for easy clock rolling! A micro bnc for masterclcok output direct to the DAC would be great.
With this approach, the DAC would get the lowest possible MC jitter, and the output of the WaveIO could be isolated. This sounds like a win/win solution to me, and while I am sure it will add to the price, the additional expense should be well worth it to those looking to achieve the absolute highest possible level of performance.
 
Jonathan,

Voyage should be the best solution, as Barrows stated, but I failed to get along with it, without help one can easily get lost in the Linux world.
Much easier would be downloading a USB installer like this one:
Universal USB Installer – Easy as 1 2 3 | USB Pen Drive Linux
and then creating a bootable stick with one normal Linux OS; Linux Mint 13 : The Linux Mint Blog Blog Archive Linux Mint 13 “Maya” released! or, smaller, Xubuntu :
Get Xubuntu Xubuntu.
They both should work out of the box. Windows 7 is a lot better than XP soundwise, so maybe there is no big difference unless you tweak the Linux with another Kernel and some scripts.
 
Approach I am trying to describe was proposed to be used in conjunction with a truly asynchronous buffer, where the samples would be clocked out with a fixed oscillator, and no PLL(s) necessary... Unfortunately, I am clearly not adequately describing this approach...
I think you're missing something. If you have a fixed oscillator, then you either need flow control, which necessitates bidirectional communication that is missing from SPDIF, or you will suffer underflow / overflow eventually. You can have a really long buffer - enough to hold an entire CD - but then this becomes annoying to wait for the buffer to fill every time you select new media. The solution is flow control signaling so the DAC can tell the source to speed up or slow down to match the fixed oscillator.

Again, you seem to be talking about data techniques (buffering) when we were discussing the possibility of software techniques for synchronizing two clocks. You described a hypothetical software algorithm that would look at the actual SPDIF headers and somehow compare them to an ideal. But not only is that not possible to implement, but it doesn't make sense if you have a fixed oscillator (as you mentioned this time). Examining the SPDIF header timing only makes sense if you have a non-fixed oscillator that you want to adjust in frequency to match the incoming clock.

Perhaps we're having terminology issues in the discussion, or perhaps you need to study digital circuit design in detail to understand the challenges of creating a low-jitter clock in an actual circuit.
 
Jonathan,

Voyage should be the best solution, as Barrows stated, but I failed to get along with it, without help one can easily get lost in the Linux world.
Much easier would be downloading a USB installer like this one:
Universal USB Installer – Easy as 1 2 3 | USB Pen Drive Linux
and then creating a bootable stick with one normal Linux OS; Linux Mint 13 : The Linux Mint Blog Blog Archive Linux Mint 13 “Maya” released! or, smaller, Xubuntu :
Get Xubuntu Xubuntu.
They both should work out of the box. Windows 7 is a lot better than XP soundwise, so maybe there is no big difference unless you tweak the Linux with another Kernel and some scripts.
Thank you to both Barrows and Yogi.
I will give it a go.
I am good with Windows but need to learn Linux which is a useful skill to have anyhow.
Fortunately, I work for a computer software company, so have a number of 'friends' there who could help me!
I find W7/Foobar very good and even more so with minimising tweaking to only a fairly small degree. If Linux can better that, I will be very pleased.
Jonathan
 
Not

missing anything:

"I think you're missing something. If you have a fixed oscillator, then you either need flow control, which necessitates bidirectional communication that is missing from SPDIF, or you will suffer underflow / overflow eventually. You can have a really long buffer - enough to hold an entire CD - but then this becomes annoying to wait for the buffer to fill every time you select new media. The solution is flow control signaling so the DAC can tell the source to speed up or slow down to match the fixed oscillator."

The Genesis digital lens did exactly this, back in the day when it was much more difficult (lack of memory, and not much in the way of DSP chips). You use a large memory cache, and control the loading of data into the memory using software without any changes to the fixed rate at which data is clocked out of the memory. The software keeps enough samples in the memory to insure that you never have "underflow". Of course, you cannot run this indefinitely, but even 8 Gb of memory is easy to have these days, and no, you do not have to wait for an entire album/playlist to load to begin playback either, you just let enough load to be sure that you will not "underflow", considering SPDIF is limited at 192 kHz, this will just be a very brief moment.
As long as one is not trying to playback many hours of gapless tracks the asynchronous, with fixed oscillator output, buffer can work without any problems (with adequate memory) without having to be bi-directional. This is the best solution for SPDIF, but as mentioned, I agree that async USB is a more elegant solution (with bi-directional control).
 
Jonathan,

I am still getting my Linux server going, looking at voyageMPD and MPDpup, pup has alot of wizards which makes setting up the compact flash card easy. If you run it off a USB drive to start, but long term get a headless pc board like an Alix or soekris and run off CF, keep the USB bus for just the dac. The soekris may have a SPDIF out, the Alix doesn't. Since the wave is XMOS, Linux sees it just fine. And it's USB.....Current ALSA drivers allow 24/192, this could change if you can configure OSS, then I'm not sure of max resolution of the WaveIO.
The Alix is $130 us from pc engines, the soekris I didn't look at. Not having excess Wchips and processes on the board does make foRr a server dedicated to serving off the network. Local disk is possible, but this may affect SQ.
Can post some links as required. I like the Linux option as it can be run as an appliance, turn it off when done, but it's such a low power device, may just stay on!