• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

exaU2I - Multi-Channel Asynchronous USB to I2S Interface

Hi Everyone,

I’ve been working on a new design for 8-channel Asynchronous USB to I2S interface. It started as a fun project and eventually became more involving than just a hobby. A couple of friends joined in and helped with the development of bit-perfect ASIO driver covering all sampling rates up to 352.8 kHz. At the present time I am testing it with a ES9018 DAC.

Here are the details:
• Sampling frequencies (kHz): 44.1, 48, 88.2, 96, 176.4, 192, 352.8
• Resolution (bits): 16, 24, 32
• 8, 4 or 2 channels for sampling rates up to 192 kHz
• 4 or 2 channels for 352.8 kHz
• Galvanic isolation between the USB ground and the I2S outputs.
• Two quartz oscillators for the 44.1 kHz and 48 kHz sampling rate groups
• FPGA implementation
• 256 kB FIFO buffer to support asynchronous operation
• Two analogue voltage regulators with filters
• Sample rate LED indicators
• USB power LED indicator
• Buffer level LED indicator
• Four I2S data outputs (8 channels) powered by the DAC power supply (3.3V or 5V)
• USB 2.0 interface, Mini USB connector
• Proprietary bit-perfect ASIO driver completely independent from the Windows sound system; No software volume control or mixing.
• ASIO driver implements automatic sampling rate switching; no re-sampling
• Works on Windows XP, Windows Vista and Windows 7.
• Tested with Foobar and J.River Media Center
• Project homepage – http://www.exaDevices.com

I am about to make the USB to I2S interface commercially available as a kit.

Any feedback is highly appreciated.
 
1/ seems that a bus designed for media makes more sense than one where media is an afterthot.
2/ in my experience it works better

It trades some hardware development (firewire) for software development (USB).

dave

Thank you, Dave. There is more than one way to do it right.
It was a design decision not to use a media interface. Making a proprietary solution gave us a complete control. We can go as high as 352.8 kHz sampling rate and we can verify bit-perfect operation in the driver and in the hardware. Ultimately what really matters for sound quality is the true asynchronous operation.

exa
 
This looks like a great product! If you need any help with the OSX driver, please drop me a line via PM. I have developed USB Devices, including firmware, with a focus on OSX, so I might be able to help.

Question: Does this design involve any use of PLL synchronization to external clock? ... or it is purely a self-clocked design based on the two 44.1 kHz and 48 kHz time base crystals?

Also: Is there any concern about jitter being introduced over the I2S link, or is that extremely minimal compared to PLL designs?
 
Thank you for offering help. I will contact you to discuss the OSX driver development.

We took every care to minimize jitter. USB data is requested by the FPGA core and stored in the device FIFO memory buffer. The FPGA core makes sure that the buffer never gets empty during playback. Data from the buffer is streamed to the I2S output. The precision of the timing of the output stream is determined only by the DAC oscillators and it is not degraded in any way by the PC clocks or by delays caused by the USB interface. There is no PLL synchronization to external clocks.

Jitter caused by the I2S connection should be minimal if a short cable is used. Further jitter elimination can be deployed on the DAC side. The DAC that we use for our own projects – ES9018 – is reclocking the I2S data internally.
 
Jitter caused by the I2S connection should be minimal if a short cable is used. Further jitter elimination can be deployed on the DAC side. The DAC that we use for our own projects – ES9018 – is reclocking the I2S data internally.
Thank you for the clarification. I would be very interested in connecting to a DAC that does not reclock, so your interface seems like a great starting point.
 
Hi Dave,
OS X drivers are on the to-do list.

FireWire in my opinion is a matter of convenience. It will make the device more expensive. Asynchronous mode of operation will work equally well with FireWire, USB or Ethernet. I’d like to hear more about the need for FireWire.

exa

Assuming all users of their music serving computer and the DAC know and implement the correct computer OS and software configurations and know how to properly implement the USB link from the server to the DAC, there is no reason whatsoever that Firewire is or should be preferred to USB. As everyone knows, as long as [ ... ... and ...] then USB is fine.

Fill in the blanks. If you can't, (or perhaps more precisely, your potential users can't) there's your reasons for FW.

It's going to add about $3 at wholesale to the cost, though (typically $10~20 at retail). On the other hand, I know that with audio gear, the difference is higher. That's social engineering, ie "what the market will bear", not a standard markup, since FW A/DD/A users tend to be in the market for semi-pro or pro live recording solutions, while USB can be sold to the masses, further lowering costs through increased sales, with the added incentive of a highly competitive market making a premium markup for something everyone else sells at standard markups unwise.

For many, that's reason enough to prefer USB. On the other hand, we're DIY'ers, not consumers of commercial boxes, so we don't (or shouldn't) care "how they do it in California".

The other is (because of the need to shave the $20 in a very competitive Windows marketplace) lots of people don't have a PC with FW.
 
Last edited:
Have you tested with other applications, like Windows 7 Media Center, VLC Media Player, or Media Player Classic - Home Cinema?

I'm curious how your drivers handle playback of DVDs and Blu-rays (either BD discs, images or MKV files). If you are going to support multichannel, it obviously needs to support these formats.

How is the device listed in Control panel, does Windows see this as a multichannel device?

Do you have any mixer control. Is it possible to control the volume of individual channels and is there a master volume control?

What about USB2 Audio Class 2.0 drivers? Supported in OSX and Linux. Hopefully Microsoft will support USB2 Audio Class 2.0 in the future. I was holding my breath, but had to exhale.
 
Thank you for offering help. I will contact you to discuss the OSX driver development.

We took every care to minimize jitter. USB data is requested by the FPGA core and stored in the device FIFO memory buffer. The FPGA core makes sure that the buffer never gets empty during playback. Data from the buffer is streamed to the I2S output. The precision of the timing of the output stream is determined only by the DAC oscillators and it is not degraded in any way by the PC clocks or by delays caused by the USB interface. There is no PLL synchronization to external clocks.

Jitter caused by the I2S connection should be minimal if a short cable is used. Further jitter elimination can be deployed on the DAC side. The DAC that we use for our own projects – ES9018 – is reclocking the I2S data internally.
It's seems very interesting. What USB Chip you use on your board? Does your project only support output? I suggest you reference XMOS USB Audio Class 2.0 reference design or C-Media CM6632 USB Audio Class 2.0 reference design. All two company's product can do what you want to do except 352.8K output.
I had some experence in develop USB Audio device driver in windows and Mac. If you need help you can PM me too.
 
Hello,
Thanks for your message on my previous thread.

You don't seem to use USB Audio 2.0 standard, as you don't have OSX compatibilty yet. I'd be happy to know how you made it :)

As a sound engineer, and now also a guy working for major brands of professionnal audio equipment, I can tell that FireWire is DEAD. Even for pro! USB is not dead: just old. USB 3.0 is of some interest. Some.

FireWire was an excellent idea. It (almost) never was correctly implemented. Compatibility issues were paramount. Finally, even Apple ditched it out of most it's products, even Macbook Pros! Developping FireWire equipment now is a nonsense. Its benefits have to be transferred to another technology that has a longer potential life.

USB is the standard. And, if designed correctly, there is no clocking problem. Ask MOTU's designers...

Where we really are heading is convergence. Network. TCP/IP Ethernet.
Just have a look at what Dante for pro audio does, Ethersound is also going native...

Didn't you just said Ethernet a few posts ago?

There is no open protocol for consumer audio streaming over TCP/IP (and especially WiFi). If you can do it, if you can have automatic delay compensation somehow for when the user is looking at videos, then... Then you'd probably better team with a few other guys, and sell a few trucks of these.