exaU2I - Multi-Channel Asynchronous USB to I2S Interface

[exa065]

Originally Posted by planet10

How many channels can it support?

dave

• 8, 4 or 2 channels for sampling rates up to 192 kHz
• 4 or 2 channels for DXD 352.8 kHz

[exa065]

Originally Posted by ra7

What you have listed in the first post is great Exa. Let us know pricing and availability.

Thank you, it will be out soon.

[rsdio]

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?

[exa065]

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.

[rsdio]

Originally Posted by exa065

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.

[qusp]

where do i sign? you might also drop acko a line as he has full 8 channel es9018 dac kit available shortly. he may offer your solution as part of the range of modules. are you also looking at integrating a digital xo as part of your mcu?

ackolabs

[Johnny2Bad]

Originally Posted by exa065

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.

[greggp]

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.

[tdtsai]

Originally Posted by exa065

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.

[NeoY2k]

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.