• 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

looks like you have a winner, unintentional confusion created by me earlier in the thread aside, i wish you luck, looks like you did your homework and the area is richer for it. i think it is wise that you create a forum, because this thread really is in breach of the forum rules, it was not a forum project, but a commercial product and should be presented as such.

and Ray, indeed it should work nicely with ackodac considering like your dac it also supports the full `1.5mhz with nos and up to 500khz with os with a 100mhz clock installed.
 
Last edited:
Unfortunately, some users have expressed concerns about sharing their experience on this thread. They say that they were approached, misled and misinformed by third parties that are interested to interfere with the success of exaU2I. In response to their concerns we will create a dedicated forum for supporting the device.

It's a shame that the DIYers that have purchased these units aren't sharing their experiences here. I suppose people have vested interests and it's usually fairly obvious that some are here to beat a drum. Best of luck with the new forum.
 
I really do not see any problems for this to continue as is. This project is dedicated to DIYers, it is available to DIYers, and it greatly enriches our knowledge and experience. We are absolutely thankful that we have access to such a wealth of knowledge as well as direct access to the unit that is ground breaking in what it attempts to do.

As far as I see we all well behaved here and this thread was not used for unit or parts ordering but to discuss this unit and to help in anyone having questions. Exa publicly announced what he is doing, shared his knowledge and plans for anyone to see and to discuss, so from that perspective we could just admire his approach and certainly not complain about it.

I hate when we break threads because for someone willing to learn there should be one place to find all relevant info. So, my vote is to keep the discussion here. Any commercial transactions, direct ordering and such is already done off this thread and it doesn't interfere with forum rules, in my mind.
 
Just to clarify that Fidelix Caprice indeed was designed and verified for 352.8kHz (DXD) playback with SDTrans 192 Rev 2.0, 2.1, and 3.0 units loaded with 2L files throughout the design and development process.

I have personally bought an "early version" and "middle generation" version of the Buffalo DAC, which we also have verified to be capable of playing 352.8kHz (and this feature may have been improved in later versions of the Buffalo), but our impression of the Buffalo units we had on hand were that 352.8kHz playback was not an original design consideration, and only further DIY modification made it (barely) possible. However, I understand that the Buffalo designers recently also are heading towards 352.8kHz and above playback...

Everyone here in Earthquake, Tsunami, and Radiation hit Japan from the Fidelix and SDTrans 192 teams (including supporting DIY members like myself) are in strong support and agreement with exaU2I and hope for great success. We deplore anyone who attempt to mislead and misinform about the exaU2I attempting to interfere with its success. We think that proper moderating of this thread by diyaudio -dot- com should be able to take care of such problems, so we wish that the thread here continues.

Bunpei wrote:
The problem was reproduced on the following DACs.
A. ESS ES9018 2ch Evaluation Board (40MHz, 100MHz)
B. Buffalo32s
C. Buffalo II DAC (80MHz, 100MHz)
D. Fidelix CAPRICE (96MHz)
You can have one another work-around. Not using "Over Sampling Mode".

RayCtech wrote:
So my conclusion are simply:
The products you mentioned are simply not designed for 352.8k -> 1536k use.
Ask the designers of those products to implement support for higher than 192k samplerates...

exa065 wrote:
Unfortunately, some users have expressed concerns about sharing their experience on this thread. They say that they were approached, misled and misinformed by third parties that are interested to interfere with the success of exaU2I. In response to their concerns we will create a dedicated forum for supporting the device.
 
..., there are
other options: ISO7240M, Si8440BB, ADuM1400CRW, IL715, ISO150, wideband transformers. But i don't know which is best one

I don't know which is the best neither.
However, at least, I experienced IL715 built in Fidelix I2S Receiver on LVDS.
I2S-HDMI.gif


I played audio files of Fs ranging from 44.1 kHz/16 bit to 352.8 kHz/24 bit on SDTrans connected to Fidelix CAPRICE, ES9018-based DAC, or TPA Buffalo II.
My ears detected no apparent degradation through the signal path.
In this case, the highest frequency signal in I2S is Bit Clock of 22.5792 MHz. IL715 is designed for 100 MHz and pulse jitter value in datasheet is 100 ps.

By the way, RayCTech connected exaU2I to Fidelix CAPRICE DAC via Fidelix I2S interface option according to his post on this thread. In this configuration, two stages of GMR isolators were involved, the first one in exaU2I and the second one in CAPRICE. I'm not sure whether he intended to do so or not.
 
Here is my perspective on the impact of jitter on the exaU2I output. The clocks are responsible for about 2ps of jitter. The FPGA causes about 40ps and the GMRs another 100ps. This would add up to about 108ps on the exaU2I I2S output. Let's assume that it is 20 times more - 2000ps. Here is the jitter sensitivity for Sabre DAC to 2ns of jitter. I don't see any reason to be concerned even if two stages of GMR are as used as presented by RayCtech on the previous page of this thread.

Sabre2nsRandomJitter.gif
 
Here is my perspective on the impact of jitter on the exaU2I output. The clocks are responsible for about 2ps of jitter. The FPGA causes about 40ps and the GMRs another 100ps. This would add up to about 108ps on the exaU2I I2S output. Let's assume that it is 20 times more - 2000ps. Here is the jitter sensitivity for Sabre DAC to 2ns of jitter. I don't see any reason to be concerned even if two stages of GMR are as used as presented by RayCtech on the previous page of this thread.

Sabre2nsRandomJitter.gif


Hmmh. It is just the Sabre!?!?.
I seriously question it's real world jitter suppression capabilities. At least my Buffallo II DAC is extremely sensitive on incoming jitter. Though I can't tell if TP gets jitter down to <2ns on the input. I'm not even sure if they do anything about it.

And then, what about different DACs, with even less jitter suppression capabilities.

I find it a bit strange, that suddenly 100ps should be more than sufficient.
 
The first evaluated setup included two isolators in the signal path due to that was what the evaluated solution included due to I wanted to test a setup that is possible to buy for others :D

I will give a technical "report" when I have evaluated the exaU2I with my own DAC.

Later when I have tweaked out all the performance there is I will maybe comment more on the audio qualities (the exaU2I are already the best I have heard from a PC based setup)..
As I now have access to a second exaU2I unit I will be able to disable the isolators on my own unit and compare...
 
The first evaluated setup included two isolators in the signal path due to that was what the evaluated solution included due to I wanted to test a setup that is possible to buy for others :D

I will give a technical "report" when I have evaluated the exaU2I with my own DAC.

Later when I have tweaked out all the performance there is I will maybe comment more on the audio qualities (the exaU2I are already the best I have heard from a PC based setup)..
As I now have access to a second exaU2I unit I will be able to disable the isolators on my own unit and compare...

Looking forward to your results. (Have you outlined your isolator setup somewhere?)

BTW.
Have you already verfied the decoupling capabilties of that device?
How much responds it to PC related optimizations, such as audiophile players, wasapi exclusive ....?


Cheers
 
Here is my perspective on the impact of jitter on the exaU2I output. The clocks are responsible for about 2ps of jitter. The FPGA causes about 40ps and the GMRs another 100ps. This would add up to about 108ps on the exaU2I I2S output.

I always hesitate to use the term "jitter" because it's definition is very ambiguous and subjective. I prefer "Phase noise" graph instead, for example,
An externally hosted image should be here but it was not working when we last tested it.

though this kind of measurements have never done for actual I2S signals.

In the arithmetic of total jitter calculation, exa065 seemed to use such a formula,
108 = sqrt ( 2*2 + 40*40 + 100*100)
Would you tell me the definition of your "jitter" quantity? On what premises can the arithmetic be applicable? Is it applicable even if your user uses bad quality DC power supply to the isolator devices on your board?
 
... As I now have access to a second exaU2I unit ...

Hi, Exa065,

Would you tell me whether two exaU2I boards can be used with one USB hub connected to one PC or with two independent USB interface cards installed on one PC so that a user may double the number of channels he assigned to one player program that runs on the one PC, maintaining a complete synchronization among channels?
 
Is it applicable even if your user uses bad quality DC power supply to the isolator devices on your board?

Hi Bunpei,

In my setup I have only used a 3.3 volt LIFEPO4 12Ah battery that powers the isolators from the FPGA, the LVDS transmitters and the LVDS receivers (powered over the HDMI cable from the transmitter side).
The isolators on the receiver side are powered by a tripple level JFET regulator that are powered from a 6.6 volt LIFEPO4 12Ah battery.
This solution works very good and the battery I have used was last charged a year ago :) It have now been running for a week 24/7 and I charged it today just to be sure it should have good performance.

Bunpei if you are concerned about "jitter" - why do you not post these informations in your own SD card player thread?

--------------------------

My own DAC are now up and running with internal SDTrans192 (direct coupled I2S) and external exaU2I (I2S over LVDS / HDMI hardware with isolators both at the exaU2I and at the DAC).
As my DAC are completely remote controlled I may switch between the internal SDTrans192 and the external exaU2I playing the same DXD music file for easy comparison.

As this thread are dedicated to the exaU2I I will focus on the exaU2I and the performance with various DAC´s and various ways of powering the exaU2I and various ways to connect the exaU2I to the DAC (isolators vs. no isolators etc.).

The test setup are a OSX file server with SSD system drive and 4T RAID10 -> Gigabit dedicated network -> dual boot OSX 10.6.7 / Windows 7 player with SSD system drive, local 2T HDD, BluRay reader, USB 2.0 and 3.0 and a eSATA 2T HDD.

Two DAC´s are now tested with the exaU2I with isolator -> LVDS over HDMI and a second isolator before the DAC.
As some here have objected to the JITTER of the isolators i will later check without the isolators in steps - first without the first isolator and then without the second isolator and then without both.
From a technical point of view this is not a interesting test case:eek:
It will only be interesting from a Fidelity point of view - will it play better without isolators??

With my own DAC that are LIFEPO4 battery powered with tripple JFET regulation for all parts of the hardware inside the DAC the results are as following so far with the exaU2I:
1. ALL samplerates and bit depths up to 384k/32bit performs without any kind of noises or other problems.
2. This are true even with the JITTER reduction turned of in the Sabre32 chip.
3. With OSF enabled the DPLL setting used are BEST - will later test what level that can work.
4. With OSF disabled the DPLL setting used are LOWEST - even with 384k/32bit and the jitter reduction disabled.
5. It is not possible to detect any difference in the fidelity with or without the jitter reduction enabled or disabled.
6. Clock speed of the DAC is 98.304MHz witch I previously have verified to be high enough to support 384k with OSF enabled, and low enough to avoid excessive noises from the DAC..

With the Caprice DAC the results are as following so far with the exaU2I:
1. ALL samplerates and bit depths up to 352.8k/32bit performs without any kind of noises or other problems.
2. 384k/32bit causes noises with the OSF enabled.
3. 384k/32bit performs noise free with the OSF disabled.
4. The default (for Caprice) settings for DPLL and jitter reduction was used.
5. The Caprice will be able to perform noise free with 384k/32bit and OSF enabled with a master clock that are 2 - 4 MHz higher than the 96MHz clock that are used..

As previously stated: The only cause to test without the isolators for the two DAC´s that so far have been used - are to test if the Fidelity of the setup improves as everything works from a technical view...

The next issue to be verified are the "possible" SONIC impact of the isolators..
After that maybe a evaluation with a Buffalo DAC if time permits it..
 
I am very pleased to announce that exaU2I is now officially the first asynchronous USB to I2S interface capable of streaming multichannel 32bit / 384 kHz data. The upgrade from 352.8 kHz to 384 kHz will be available to existing exaU2I users as a software download. I would like to thank all beta testers and early adopters for their feedback and support during the development of the 384 kHz ASIO driver.
 
I have now bypassed the GMR galvanic isolators on the exaU2I device.
The technical functionality have not changed in any way, and if there was any changes to the Fidelity the changes was to subtle to be noticed with the 5 minutes it took to solder and connect again.

I will bypass the second galvanic isolation in the receiver end and if there are any notifiable changes I will post it here.

My results may not be valid for other setups as my setup are running mainly from battery sources and the PC etc. are connected to the mains via a very effective mains filter.