• 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

Sorry exa, for the interruption with sort of unrelated disscussion, but I am positive I will be plugging exa device to a LP/Thunderbolt pretty soon. :):):)

This is all very exciting. I am looking for alternatives that will allow me to overcome the limitations of the device. There are 3 possibilities. (1) Develop new drivers (2) Develop new hardware (3) Both . :)
 
I can't understand why you guys talk about FW again and again. From technical point of view there is no difference what kind of interface you use - USB, FW, Ethernet, Bluetooth etc. The fact that pros use FW has nothing to do with level of output jitter.
If you want FW because you like this name or you like to feel like pro because you use the same interface go ahead but this won't give you nothing more than that. Understand it.
If you disagree post firm advantages of FW or leave this FW talk.

P.S. I'm not fan of exa2UI and I do not have it - its to expensive for me because of currency relation.
 
I can't understand why you guys talk about FW again and again. From technical point of view there is no difference what kind of interface you use - USB, FW, Ethernet, Bluetooth etc. The fact that pros use FW has nothing to do with level of output jitter.
If you want FW because you like this name or you like to feel like pro because you use the same interface go ahead but this won't give you nothing more than that. Understand it.
If you disagree post firm advantages of FW or leave this FW talk.

I agree with this. Further, Firewire ports on many consumer motherboards are already becoming an afterthought. The drive now is towards adding in USB 3 ports (using NEC's controllers) and I suspect Thunderbolt will pick up a lot of interest when made available to more platforms.
 
I agree with this. Further, Firewire ports on many consumer motherboards are already becoming an afterthought. The drive now is towards adding in USB 3 ports (using NEC's controllers) and I suspect Thunderbolt will pick up a lot of interest when made available to more platforms.

Regarding USB 3 - I have tested the exaU2I on various USB hardware implementations including USB 3 with NEC controller.
All tested USB implementations I have tried works without problems,
and I will in a day or two check if there are any differences in the Fidelity performance between the various USB hardware implementations (on the PC).
 
Regarding USB 3 - I have tested the exaU2I on various USB hardware implementations including USB 3 with NEC controller.
All tested USB implementations I have tried works without problems,
and I will in a day or two check if there are any differences in the Fidelity performance between the various USB hardware implementations (on the PC).

Yes, the NEC controller handles USB 2.0 compliant devices fine in my experience. In essence it might be better to place the exaU21 by itself on the NEC controller as it is bridged directly to the PCIe bus rather than relying on the master USB hub. Looking at the datasheet, clock modifications are possible, although tricky.
 
Last edited:
But, again, if you are using a USB-reclocker then you are misunderstanding the proper solution. Reclocking is different technology than having the DAC run as master clock. USB-Audio offers too many options, I suppose, because this should not be so confusing.

The real problem is the asynchronous clocking scheme.

The best and most consequent clock implementation I came across is the EC-designs SD-card player.
One clock for everything. No intermodulations of any kind.
 
Yes, the NEC controller handles USB 2.0 compliant devices fine in my experience. In essence it might be better to place the exaU21 by itself on the NEC controller as it is bridged directly to the PCIe bus rather than relying on the master USB hub. Looking at the datasheet, clock modifications are possible, although tricky.

I have now compared the Fidelity of the exaU2I when connected to the standard USB 2.0 hub and the NEC USB 3.0 controller.

In my setup the differences are easily detected and the exaU2I stays connected to the NEC USB 3.0 controller ;)

When I received the exaU2I the first thing I checked was that the exaU2I was recognized by the NEC USB 3.0 controller running OSX 10.6.7..
So if the OSX drivers become available I expect the NEC USB 3.0 controller can be used with exaU2I also when running OSX.
 
I am curious to why not those that have received and evaluated the exaU2I are writing about their experiences here??

Have all the exaU2I units been sold to competitors of exaDevices :eek:

I cannot be the only one that have managed to connect the exaU2I and have it running as I now have connected it to several DAC in several ways and it have worked every time without any issues...
 
Tweaking of the exaU2I...

Since the exaU2I are a DIY product I have made an easy to change / modify setup and I have tweaked the exaU2I in several ways just to check if the already excellent performance of the standard product can be tweaked further.

The attached pictures are some days old and I have since then reconfigured and are evaluating other "upgrades".

The setup in the pictures have a Corian base and top and the 5 volt USB voltage are disconnected and the FPGA, clocks, GMR´s and LVDS are powered by LIFEPO4 battery.

The difference in fidelity between the standard exaU2I and the tweaked exaU2I (pictured) and the current tweaked exaU2I are not very big as the standard unit performs excellent.
For me every little improvement are of importance and my setup will be tweaked until there is no more to gain :D
 

Attachments

  • exaU2I eval II-1.jpg
    exaU2I eval II-1.jpg
    195.3 KB · Views: 471
  • exaU2I eval II-2.jpg
    exaU2I eval II-2.jpg
    194.4 KB · Views: 449
  • exaU2I eval II-3.jpg
    exaU2I eval II-3.jpg
    197.6 KB · Views: 446
Last edited:
In my setup the differences are easily detected and the exaU2I stays connected to the NEC USB 3.0 controller ;)


This is certainly wonderful but can you suggest any reasons why an async, galvanically isolated device should be sensitive to the type of interface. I also tried async usb with the vain hope that it will eliminate cable and port effects but it appears every bit as sensitive as the old 2707 isochronous chip.
 
This is certainly wonderful but can you suggest any reasons why an async, galvanically isolated device should be sensitive to the type of interface. I also tried async usb with the vain hope that it will eliminate cable and port effects but it appears every bit as sensitive as the old 2707 isochronous chip.

I believe the answer may simply be "noise" of all kinds.
Of course there are also many other issues that will have impact,
but reducing noise in power supplies and reducing the noise the power supplies sends back to the mains have always improved my setups.
I have never been able to reach a level where the improvements stops...
 
I believe the answer may simply be "noise" of all kinds.
Of course there are also many other issues that will have impact,
but reducing noise in power supplies and reducing the noise the power supplies sends back to the mains have always improved my setups.
I have never been able to reach a level where the improvements stops...

You could try shunt regulating the 3.3V and 1.2V feeds to the NEC chip if you really want to go to the nth degree - I am thinking of doing this at some point.
 
I can't understand why you guys talk about FW again and again. From technical point of view there is no difference what kind of interface you use - USB, FW, Ethernet, Bluetooth etc. The fact that pros use FW has nothing to do with level of output jitter.
If you want FW because you like this name or you like to feel like pro because you use the same interface go ahead but this won't give you nothing more than that. Understand it.
If you disagree post firm advantages of FW or leave this FW talk.
You are correct that there are not necessarily any electronic advantages of FW over USB. However, the ability to use standard drivers limits the choices. An electrical interface must have standards available for audio which meet the needs of the interconnect. Ethernet would work, too, but ethernet does not specifically define an audio standard for transport. USB and FW do have such protocols, but USB-Audio has too many variations, and the ones needed are missing from Windows. FW has had isochronous audio protocols since the beginning, so the combination of electrical and protocol compatibility makes FW unique. Unfortunately, I suppose Windows has poor support for FW, too. But in those situations where FW is supported, there is a much lighter load on the operating system to support streaming audio - and this is another advantage of FW over USB.

We should probably start another topic if FW becomes a popular side-subject.
 
Last edited:
You are correct that there are not necessarily any electronic advantages of FW over USB. However, the ability to use standard drivers limits the choices. An electrical interface must have standards available for audio which meet the needs of the interconnect. Ethernet would work, too, but ethernet does not specifically define an audio standard for transport. USB and FW do have such protocols, but USB-Audio has too many variations, and the ones needed are missing from Windows. FW has had isochronous audio protocols since the beginning, so the combination of electrical and protocol compatibility makes FW unique. Unfortunately, I suppose Windows has poor support for FW, too. But in those situations where FW is supported, there is a much lighter load on the operating system to support streaming audio - and this is another advantage of FW over USB.

We should probably start another topic if FW becomes a popular side-subject.

My knowledge about FW audio support is poor but as you said FW has isochronous mode defined which is not what we want. In isorchonous mode data source (PC) is a clock master like with PCM270x. If we want achieve lowest possible jitter , clock source (precise low jitter XO) should be located close to DAC and this requirement is the main reason for creating exa2UI.
I do not know FW solutions you talking about but I'm not sure it offers best best jitter performance which we want here.
 
My knowledge about FW audio support is poor but as you said FW has isochronous mode defined which is not what we want. In isorchonous mode data source (PC) is a clock master like with PCM270x. If we want achieve lowest possible jitter , clock source (precise low jitter XO) should be located close to DAC and this requirement is the main reason for creating exa2UI.
I do not know FW solutions you talking about but I'm not sure it offers best best jitter performance which we want here.
Sorry, but isochronous has many different meanings. In the case of FireWire, isochronous merely means dedicated audio bandwidth, which is different from FireWire disks which only get bandwidth when it is available.

Rest assured that FireWire audio interfaces can and do act as the clock master. FireWire is a peer-to-peer interface, so there is no requirement that the PC be master of anything, clock or data. Also, you can be sure that I would not be talking about FireWire-to-I2S except that it is possible for the DAC to be master clock.