Forgive me if this has been answered, I'm sure it has, is this device EXAU2l coupled with the buffalo ii and or iii capable of stable dsd playback using A Mac with X/Lion and pure music software? Also, if using boot camp with windows 7 will it operate with the same as if it were om a PC? I'm am not very knowledgable when it comes to these sorts of things.
Thank You
Thank You
Sorry, at this time DSD works only on Windows with our proprietary DSD player.
exaU2I 32/384 USB -> I2S - Version 2
Gentlemen,
It's been almost a year since the release of exaU2I 32bit/384 kHz async USB interface. exaU2I was designed in a very minimalistic way, using ordinary clocks and USB power. We utilized "jitter-causing" GMR insulators. Yet some called the exa's sound "in a league of its own". Many hated it because it challenged the status quo. The ones that were brave to try the exaU2I love it. We enjoy great support from our users.
It is time to bring the device to the next level. We are considering making a next generation USB to I2S Interface. Tell us what you want it to be. We are considering 2 vs. 8 channels, price over performance, to GMR or not to GMR. Let us know what is important to you.
Happy New Year,
exa065 and the exaSound Team
Gentlemen,
It's been almost a year since the release of exaU2I 32bit/384 kHz async USB interface. exaU2I was designed in a very minimalistic way, using ordinary clocks and USB power. We utilized "jitter-causing" GMR insulators. Yet some called the exa's sound "in a league of its own". Many hated it because it challenged the status quo. The ones that were brave to try the exaU2I love it. We enjoy great support from our users.
It is time to bring the device to the next level. We are considering making a next generation USB to I2S Interface. Tell us what you want it to be. We are considering 2 vs. 8 channels, price over performance, to GMR or not to GMR. Let us know what is important to you.
Happy New Year,
exa065 and the exaSound Team
Last edited:
The exaU2I has always been a fascinating product. Here is what I would like to see next:
Must Have:
A) USB Audio Class compliant, i.e., Isochronous endpoints operating in Asynchronous rate feedback mode
B) Ability to take Master Clock and/or Word Clock from the DAC board
Nice to Have:
C) On-board DSP (TMS320, SHARC, etc.) with downloadable firmware or plugins
D) Single circuit board (no daughter boards)
E) FireWire 800 or 400 interface (I realize this is not likely to happen)
Last edited:
Happy New Year exa065!
I believe you have received most of the inputs you need during the period of time that have already passed.
As I now have both ready the guest room and a audio setup in La Casa Muda so why dont you simply drop in for a visit so we can discuss this over a superb dinner
agree!!!
Having Firewire support would be nice, but then again, you'd need another set of proprietary drivers.
Considering 2 vs. 8 channel?? How about both. Make two 2nd generation interfaces, one optimized for 2 channel, the other for 8.
Ideally, it would be nice to have a single solution with the ability to switch between stereo and multichannel modes, but that would probably need to be accomplished on the DAC board, not the interface.
There are FireWire audio interfaces which work without installing any driver at all. Of course, this is on Mac OS X where Apple has implemented the standards. Windows previously had poor support for FireWire, and although people tell me that the support is better, I'm still not sure whether that means these same driver-less FireWire audio interfaces would also work on Windows without drivers.
Happy New Year exa065!
I believe you have received most of the inputs you need during the period of time that have already passed.
As I now have both ready the guest room and a audio setup in La Casa Muda so why dont you simply drop in for a visit so we can discuss this over a superb dinner
Thank you for the invitation, RayCtech. I look forward to listening to your very custom system. To make the visit more exciting, I will put together a prototype. Give me some time to get ready.
exa065
Hi rsdio, I think that you've mentioned before that you are working on a FireWire / DSP device so I am sure that you know these technologies and their advantages.
We will be more interested to take again the road less travelled. Our proprietary driver technology is a major contributor to the realistic and detailed sound of exaU2I. We will continue to improve it for the next release.
USB Audio Class compliance is a major convenience for the end users, there is no need for driver installation. We wouldn't trade our unique advantages in sound quality for convenience.
FireWire is a great established technology. Again, our position is that changing the pipeline will not contribute to sound quality. If we decide to change it for the sake of convenience, we would go for something more exciting, like wireless Ethernet.
Our aim is to create an interface that is as bitperfect , noiseless, and jitter-free as possible. DSP is out of scope for us. It is a feature for a different device.
Your other suggestions - single PCB and external clock capability are noted on the requests list.
I hope I haven't disappointed you too much, we are looking in different directions. There is more than one way to do things right. Thank you again for your professional contribution to the ongoing exaU2I discussion.
Thanks, we can build two devices. I am trying to understand what are the important features for the majority of the users.
Last edited:
I have a multichannel firewire interface for Windows 7 and to get Windows to recognize it as a multichannel device, I needed custom drivers. This included both WDM and ASIO drivers. The ASIO driver works great for audio only apps, and the WDM driver works well with apps for watching DVDs and Blu-rays, like Windows Media Center.
Rsdio, I've just deleted your post. The point of the discussion here is to go forward in a constructive way and to make exaU2I more useful. This is not the place for another fight.
We say that out drivers are better because we can bypass OS limitations, we have full control over the processing from beginning to end, and we can verify their performance. We say that the sound is better based on subjective personal experience and user feedback. My comments about minimizing noise are not related to driver technology. I was talking about goals for the device.
We are interested to offer an alternative to standards. Our approach is to minimize complexity and processing. We believe in scientifically sound solutions, and we are satisfied when there is correlation between measurements and subjective tests.
Again, different approaches and solutions can be discussed on other forums. This thread is about exaU2I, and exaU2I is an alternative device.
We say that out drivers are better because we can bypass OS limitations, we have full control over the processing from beginning to end, and we can verify their performance. We say that the sound is better based on subjective personal experience and user feedback. My comments about minimizing noise are not related to driver technology. I was talking about goals for the device.
We are interested to offer an alternative to standards. Our approach is to minimize complexity and processing. We believe in scientifically sound solutions, and we are satisfied when there is correlation between measurements and subjective tests.
Again, different approaches and solutions can be discussed on other forums. This thread is about exaU2I, and exaU2I is an alternative device.
Please explain how your control over the processing from beginning to end is superior to bit-perfect, jitter-free transports. All evidence indicates that custom drivers are not necessary to achieve bit-perfect, jitter-free performance.
Please also explain how your custom driver minimizes complexity and/or processing.
Note that my experience is with OSX, where CoreAudio presents the absolute minimal interference between an audio player application and the audio hardware. I realize that most (all?) of your existing customers are using Windows, but I would like to see new exaDevices products fully support the existing, simple, unprocessed options in CoreAudio on OSX.
Good you have evidence @rsdio
I have observed that your statement are not true and that most hardware and most software are ONLY so called bit-perfect in isolated study cases.
I have also observed and verified that most DAC chips are not bit-perfect in their data manipulations either.
I do not need to prove anything as my observations are clearly documented in the standards that are lying in the bottom of digital audio - if you do not agree then start studying the basics.
I may say as much as when a 16 bit audio file are played and the so called bit-perfect chain to the DAC are following the standards - then you may get bit-perfect performance ONLY if you use a pure 16 bit DAC..
It seems that you are not aware that the exaU2I hardware does not include a DAC. Therefore, while your observations would be very important if I was talking about a DAC, they're quite moot in this thread.
I have confirmed bit-perfect performance by looping back the digital data and comparing the source to the final data after it has traveled across the bus twice. Jitter-free performance cannot be affected by host computer drivers when the clock source is the DAC, and so while I have not confirmed this empirically, I have proven it as a priori truth. These feats are accomplished by many audio interfaces, both proprietary and standards-based.
There are plenty of arguments to be made about DAC technology, and I do not want to get into them in this thread, precisely for the reason that the exaU2I (and presumably also the new improved versions) does not include a DAC. I think it's great that exaDevices decided to create a platform where the bit-perfect, jitter-avoiding transport is the entire raison d'etre for the product because it skirts all of these imperfections and leaves them to the particular DAC implementation to solve. Of course, the exaU2I does facilitate certain aspects of the solution with various isolation techniques.
Back to the topic...
I would like to see:
1. Very low phase noise oscillators, like Crystek CCHD series-reason being that I prefer to synchronously clock my DAC, providing masterclock from the USB interface, so phase noise/jitter in the I2S output is critical.
2. Ultra low noise/impedance local shunt regulators, one for each onboard oscillator to allow the oscillators to perfrom their best, and not back modulate the power supplies.
3. Users choice to use the GMRs or not, with separate output headers, and I would prefer micro bnc (for U.FL) for the non-isolated I2S output.
4. Option to send masterclock back to the exa from the DAC over I2S.
5. Oh yeah, prefer two channel only here.
RSaudio: if you have played around with any music software (Pure Music, Audirvarna, etc) you already know that "bit perfect" is not all that matters-it is pretty easy to get bit perfect output from iTunes alone, but it sounds like crap compared to good player software, eventhough they are all bit perfect. I suspect that the exa drivers just help streamline the data path and processing, just as the better player software does. What this does not help is the compromised USB hardware on most computers-interestingly, I recently switched to a linux based player, with a dedicated SOtM USB output card, better sound... but I digress.
I would like to see:
1. Very low phase noise oscillators, like Crystek CCHD series-reason being that I prefer to synchronously clock my DAC, providing masterclock from the USB interface, so phase noise/jitter in the I2S output is critical.
2. Ultra low noise/impedance local shunt regulators, one for each onboard oscillator to allow the oscillators to perfrom their best, and not back modulate the power supplies.
3. Users choice to use the GMRs or not, with separate output headers, and I would prefer micro bnc (for U.FL) for the non-isolated I2S output.
4. Option to send masterclock back to the exa from the DAC over I2S.
5. Oh yeah, prefer two channel only here.
RSaudio: if you have played around with any music software (Pure Music, Audirvarna, etc) you already know that "bit perfect" is not all that matters-it is pretty easy to get bit perfect output from iTunes alone, but it sounds like crap compared to good player software, eventhough they are all bit perfect. I suspect that the exa drivers just help streamline the data path and processing, just as the better player software does. What this does not help is the compromised USB hardware on most computers-interestingly, I recently switched to a linux based player, with a dedicated SOtM USB output card, better sound... but I digress.
I hope USB High-speed is isolated in the new design by embedding such a technology.
Core Modules, Daughter Boards, Core Development Kits for USB Extension - Icron Technologies
Core Modules, Daughter Boards, Core Development Kits for USB Extension - Icron Technologies
Here is my input of what I would like to see in a revised design:
- Ability to support synchronous operation of the Buffalo DAC. The exa-device has two oscillators. It should therefore be the clock source when operating the Buffalo-DAC in synchronous mode with its ASRC disabled, since it can generate both multiples of 44.1 and 48 Khz. This means that the oscillator on the Buffalo needs to be removed.
- Because of the above, a galvanic connection is needed for this clock. The galvanic isolation should therefore be moved to the USB-side.
Since the synchronous option appears to elevate the sound quality yet another notch (RayCtech, Bunpei), such an implementation would be very desitrable. I also support the suggestion by other posters to incorporate high quality regulators, if this increases the sound quality.
- Ability to support synchronous operation of the Buffalo DAC. The exa-device has two oscillators. It should therefore be the clock source when operating the Buffalo-DAC in synchronous mode with its ASRC disabled, since it can generate both multiples of 44.1 and 48 Khz. This means that the oscillator on the Buffalo needs to be removed.
- Because of the above, a galvanic connection is needed for this clock. The galvanic isolation should therefore be moved to the USB-side.
Since the synchronous option appears to elevate the sound quality yet another notch (RayCtech, Bunpei), such an implementation would be very desitrable. I also support the suggestion by other posters to incorporate high quality regulators, if this increases the sound quality.