XMOS-based Asynchronous USB to I2S interface

All kernel and kernel device driver code runs at a higher priority than any application. The only way Microsoft could have eliminated the possibility of such long latencies would have been to restrict the peripherals that would be supported the way Apple and HA server vendors have.
What sort of peripheral "restrictions" are you talking about? The list of peripherals supported by Apple is generally larger than Microsoft's, at least for the audio devices that I care about. There are unsupported devices on OSX, but that's not due to restrictions, but rather that the hardware vendor does not care to take the time to make their device comply with standards or write a custom driver.

If you can specify particular restrictions that Apple applies to peripherals, then your claims might appear valid. As it stands, it sounds like you're just reiterating unsubstantiated claims from folks who do not really know what they're talking about. By the way, I develop USB hardware and write drivers for NEXTSTEP and OSX, and I have never seen any restrictions - at least not anything that would deny support for any piece of hardware.
 
Perhaps it is no longer the case but at least until I retired the list of peripherals -- not just audio, but of all types -- was much broader for Windows. To some extent that reflected the tiny market share of Apple in those days. The way Linux could be made to even approach Unix in reliability was to restrict storage, network, and pci adapters to a short list and test them extensively. I am not attempting to disparage Apple. I meant that as a general approach of how one might go about limiting the negative impact of drivers whose latency would negatively impact the entire system.

If I had to choose but a single OS to run it would be Linux. If, today, I was asked by someone whose primary interest was audio for a recommendation it would be Apple. I will continue to run more Windows boxes for two reasons. My wife is more comfortable with the UI, and they are dirt cheap (along with Linux). If I tried to use WaveIO with a Mac from, say, 2001, what might I expect?

I reread your post and understand now that you meant a list of actual restrictions. That list exists for server hardware but I have never looked for approved list like the WHQL list published by Microsoft. Is there such a list?
 
Last edited:
Hey, you did me a favor by getting me to think about the Asus mobo Intel PIII system I purchased in 1998. The only hardware upgrade is a USB2 port. It took only minutes to install the drivers and have bit perfect music playing. Latencies are much lower than I would have expected.
 
Perhaps it is no longer the case but at least until I retired the list of peripherals -- not just audio, but of all types -- was much broader for Windows. To some extent that reflected the tiny market share of Apple in those days.
I would say that it was entirely due to the market share. Apple has no control over what drivers are released by third parties. Therefore, any driver that is missing is not due to any restriction, per se, but rather due to lack of effort on the part of the hardware vendor. This is the case for OSX, which has been shipping since 1997, and became prevalent starting around 2001.

The way Linux could be made to even approach Unix in reliability was to restrict storage, network, and pci adapters to a short list and test them extensively. I am not attempting to disparage Apple. I meant that as a general approach of how one might go about limiting the negative impact of drivers whose latency would negatively impact the entire system.
Again, you are using terms like "restrict" and yet Apple does not manipulate the list of hardware that they support. Quite literally, the only hardware that Apple supports is the hardware that they manufacture themselves plus hardware that complies with open standards. This is the reason that I am complaining about your terminology, because Apple is not making any restrictions whatsoever. If Apple makes the hardware, then they provide a driver. If there is a general standard, then Apple provides a generic driver with the ability to override the matching driver.

Third party hardware developers are always free to create and distribute drivers. There is nothing that Apple can do to restrict this. Thus, if you find yourself wishing there were a driver for some piece of hardware, then you need only blame the hardware manufacturer for not supporting Apple.

I reread your post and understand now that you meant a list of actual restrictions. That list exists for server hardware but I have never looked for approved list like the WHQL list published by Microsoft. Is there such a list?
I do not know about Microsoft. I never owned PC clone hardware, and after I quit working for Microsoft I stopped keeping track of any details there. My rough impression is that FireWire support is so bad that Microsoft engineers actually think that the standard itself is flawed - or at least they did a few years back. Yet FireWire audio devices work flawlessly under OSX.

See my comments above - for Apple, they support the hardware that they make plus hardware that implements standards. Since you can't really build an Apple from non-Apple parts, there isn't really a need for a list. The one exception is Darwin - the open source version of OSX - where the community has contributed drivers for non-Apple hardware that is proprietary. I have not used any Darwin drivers, though, but Apple may have rolled them in.

I am curious what your experience has been at the driver, rather than app level, rsdio. I was amazed that you were able to write code for FireWire and have it run with USB. On what platforms were you able to make that work?
Looks like you deleted this comment before I could reply. Just to clarify, my "FireWire" code was not actually specific to FireWire, but specific to CoreAudio. That's the reason I was able to write code while testing with a FireWire audio device and have it work with USB audio devices, too. It might also be worth pointing out that I did not write driver code that worked for both hardware bus types, but app level. Driver code is always hardware specific and therefore almost always bus specific.

Apple has a great design with CoreAudio. It is a pull model, not a push model, so the DAC always has the master clock. For class-compliant devices, the timing critical code is part of Apple's generic driver. Hardware that is proprietary merely requires a CoreAudio driver and then all audio code works perfectly, on equal par with FireWire or USB audio. The only caveat is that the custom driver must get the sample clock timing alignment to the CPU clock just right, or things fall apart. But that is not impossible with any proper hardware, it just takes some coding skill.
 
So here's my situation. I purchased a D510MO, fanless power supply, SSD, a legal boxed copy of XP, and WaveIO for under $300. It works perfectly as far as I can tell. All of the components are new and I could switch to Linux at no cost. Would I have been better off choosing any other configuration at that cost? Would any other configuration have delivered a more perfect i2s stream that would sound better if cost were no object?
 
I purchased a D510MO, fanless power supply, SSD, a legal boxed copy of XP, and WaveIO . . . Would I have been better off choosing any other configuration at that cost?

I doubt it. I've built three PC-Audio-only systems, two for friends, using the D510MO or near equivalent. All are successful. There are better motherboards to be had (such as the Fit-PC2) but they cost more.

SQ differences from mobo to mobo, PSU to PSU and whatever to something else can be marked when using conventional, adaptive mode USB-to-I2S devices but it's a moot point how much difference they make when using a WaveIO and asynch protocols. Less debatable is that you would not be getting them for $300 all in . . . you've chosen well IMHO.
 
Last edited:
@ tassosk and crazyfog: you have PMs, thank you!

Hi Lucian,

Just inquiring if you had shipped my WaveIO? Last I inquired you said it was ready but it needed some final touches. I used the faster shipping in my payment.
Thanks
Do

I got it Do :) It's ready though I only have two days on a week at my disposal to send parcels outside EU and I have to cope with custom's schedule even if I want it or not :bored:: Tusday and Thursday. Well, this Tusday I'll be out of town but next Thursday your WaveIO will be dispatched to you.
Kind regards,
L
 
FIT-PC2

I doubt it. I've built three PC-Audio-only systems, two for friends, using the D510MO or near equivalent. All are successful. There are better motherboards to be had (such as the Fit-PC2) but they cost more.

SQ differences from mobo to mobo, PSU to PSU and whatever to something else can be marked when using conventional, adaptive mode USB-to-I2S devices but it's a moot point how much difference they make when using a WaveIO and asynch protocols. Less debatable is that you would not be getting them for $300 all in . . . you've chosen well IMHO.

Ryelands was kind enough to recommend the FIT-PC2 to me. Out of the box, with stock wallwart PS, it was by far the best SQ I have heard [over USB to DAC]. They are also beautifully crafted and engineered and tiny size. Built-in wireless networking for Remote control with UVNC running 'headless'.

I run Windows 7 on it optimised to a small extent and it is great. The FIT has no issues running that OS although it is relatively low powered.

I only buy used gear and the FIT-PC2 goes on ebay for c.£160 approx $300, which I consider a steal.

I have a WaveIO on order from Lorien (as does Ryelands) and am looking forward to the great SQ I can expect from it.
 
Value base audiophile

The D510MO sounds like a great choice in value audio. I have been running even cheaper by using cast off laptops. I have one with a relatively current dual core P4 processor, and another with an older 1.8ghz Centron. Both have more than enough power for the task. Main problem with laptops is to keep them idling so they are happy running with fan off.
At the risk of causing a religious war, whoever it was that said slimming the OS makes no difference.. you are ill informed. It does, and until you hear it, it seems inconceivable. I too am 30 years in IT industry and it did not make logical sense but it is a fact. The closer you can get to a minimalist OS on a minimalist processor the sweeter the sound you will hear. It is not a requirement. I agree that WaveIO sounds great driven with full blown OS on full blown motherboard. Also sounds great powered from USB. But it sounds better with a good linear power supply and a super slim processor ahead of it.
I do plan on trying out a slim Linux distro on an ALIX or Atom board. Intuitively I expect that it will be similar to the FitPC headless reported earlier. Perhaps even better as there are fewer features on the board to create noise. For me this will be challenging as I know nothing about Linux.
Speaking of power supply, I like to experiment as part of my learning process. I have a simple CLC filtered supply with good caps. It is a breadboard set up with alligator clips, so easy to swap parts. For the choke I swapped in the transformer from a microwave oven. These things are a huge chunk of iron with a primary wound with about 18gauge magnet wire. A mere 1.8 ohm resistance. Using the primary as the choke element, the sound impact on WaveIO was pretty significant. A big jump in micro detail and 3d. Lots of texture. I had to go back and do an A/B test to see if it was my imagination. Not so. The point is, there is lots of fun to be had experimenting with the power supply. No, not required to make sound, but if DIY is part of your interest, there is a lot to be explored in this area as well.
 
Love that oven "choke" and the Fit-PC is really cute. Part of the reason my cost was so low is that XP Home can easily be made to run remote desktop (see: Install and Enable Remote Desktop in Windows XP Home Edition My Digital Life).

That means no keyboard, monitor, or mouse is required. You can control your music box from any other windows or linux computer on your network and a portable makes a truly full-featured remote :D

I have been disturbed by the DPC latencies on my portables but only those measured on the D510MO count when controlled remotely.
 
one last thing

I forgot to ask if anyone could recommend a USB to i2c converter. They are all over eBay and the web but all of them require a driver so if someone has run DPClat during an ongoing i2c conversation and knows one model to be particularly good while WaveIO is playing 192/24 . . .

Surely the time is not far off when a beagle board or something similar will be able to handle UPNP, stream i2s to dac(s), control the dac(s) registers thru i2c, and cost much less than $300 but I hope to listen to more music and write less code between now and then
 
I forgot to ask if anyone could recommend a USB to i2c converter. They are all over eBay and the web but all of them require a driver so if someone has run DPClat during an ongoing i2c conversation and knows one model to be particularly good while WaveIO is playing 192/24 . . .

Surely the time is not far off when a beagle board or something similar will be able to handle UPNP, stream i2s to dac(s), control the dac(s) registers thru i2c, and cost much less than $300 but I hope to listen to more music and write less code between now and then

I have no i2c recommendations unfortunately, haven't used any of them.

I will be using a beagle bone in much the way that you suggest in my headphone system though.

My plan is to have beagle bone act as usb host and drive audio through WaveIO into DAC. At the same time have spi/i2c control the dac and a local display and eventually a web based ui through the ethernet port for set of different DAC filters/registers that are not interacted with as often.

My preference is not to use UPNP though, MPD will fill this role for me.
 
Wishes and acknowledgements

Let me add one more restriction on the USB to i2c converter -- I must be able to power it externally. While I am at it I might as well wish for one that could fool the Wolfson evaluation software into driving the DACs. :D

My preference is not to use UPNP though, MPD will fill this role for me.

My experience with UPNP has not been smooth and it is only fair to acknowledge Chris as my source of ideas for what will supplant the current overkill sitiuation. I am aiming at a poor man's Akurate.
 
Can you tell me how a I2S data signal should look like? I have a problem my Buffalo III does not accept the I2S signal coming from WaveIO.
I could check it with my oscillo.
I2S should look like digital data. Unfortunately, a single-trace 'scope cannot tell you whether the data is good or bad - you really need to see the clock and data on the same time scale. Often, if I2S is not working, it's the polarity of the clock or the timing / phase shift between clock and data. There should be data sheets for both the Buffalo III and the I2S chip on the WaveIO that you can compare to see what needs to happen for compatibility. Note that my answer is generic to all I2S links, since I have not used your specific setup myself.
 
physically it would look like this, from Wave's output going to BII
 

Attachments

  • pictogram.jpg
    pictogram.jpg
    94 KB · Views: 799