With respect to the Windows setup issues I was a beta tester of Windows NT and a VMS (Windows NT = WNT is a shift left from VMS) internals support engineer for years before that..
I used Windows NT for over a year before I installed the first official Windows NT installation at the Norwegian Microsoft headquarters on the Microsoft product managers PC (the PC was also supplied..)
Hmmh. Windows NT.
Didn't know you were involved in that mess?
Knowing that now puts you of course into a different light.
Due to the change from 32FS (pure 16 bit) to 64FS clocking to allow for bit depths above 16 bit the Philips and Sony people obviously was stuck with a dilemma...
They had basically two options as I see it:
1. Revise the I2S specifications for proper operation.
2. Revise the I2S specifications in a quick and dirty fashion and allow for easy operation of 16 - 32 bit transmitters and 16 - 32 bit receivers at the cost of accuracy..
They selected option 2 and if these I2S specifications are followed the true fidelity are compromised.
I was for many years able to avoid the problems by only playing 16 bit sources and only use pure 16 bit DAC´s as this is the only combination that avoids the I2S specifications errors.
With 24 bit sources and 24 bit DAC´s and 32 bit sources and 32 bit DAC´s the problems are also avoided.
But to be able to play 16 - 32 bit sources with a 32 bit DAC as the ES9018 the sender side needs to correct the I2S specifications errors for bit depths between 16 and 32 bit.
Due to most music are available as 16 and 24 bit the correction can be implemented in 8 bit steps..
exa065 / exaDevices developed a version of the ASIO driver that implemented the correction options after my request.
As they do NOT use a general available ASIO driver, but have developed their own ASIO compliant driver that have full control from the player application to the registers in the DAC they could implement my requested changes at once.
A exaU2I Configuration Tool to manually change the setup was made for the beta testing and measurements in a controlled environment.
This exaU2I Configuration Tool are not available to the public as the ASIO driver now have included a check box for selection of the automatic LSB extensions corrections.
Screenshoots of both the exaU2I Configuration Tool and the ASIO driver configuration screen are attached.
In the finalized version the automatic LSB extensions (when selected) requires a bitperfect source.
If the volume control or any other manipulations are used (DLL´s, pluggins etc.) the LSB extensions corrections are automatically turned off as it will only work as intended with bitperfect sources.
The screenshoots are from the latest versions of the Configuration Tool and ASIO driver.
The updated ASIO driver will be available from exaDevices as soon as they have finished the quality controls.
I have been using a SDTrans192 SD card player as my primary audio source for a period of time and also this device have implemented the automatic LSB extensions.
The firmware (SDTrans192) was first done as a paid job exclusively for me, but became a standard of the SDTrans192 later.
When the users of exaU2I have installed this new updated driver there are very easy to check or uncheck the automatic conditional LSB extensions in the ASIO driver configuration panel as shown in the attached screenshots.
For those that wonders if there are any improvements in the fidelity the answers are simply yes.
Most of the harsh "digitalis" distortions are removed and everything in respect of fidelity improves.
I expect there will be posted reports as the exaU2I users have installed their devices and upgraded the ASIO drivers..
When working with exa065 on the new ASIO drivers I became aware of the fact that when the exaU2I are configured as a 2 channel device the L & R channel are repeated on the three remaining I2S channels.
This makes it very easy to connect a ES9018 DAC as there is no need of tweaking with register settings to utilize the ES9018 as a 2 channel device...
Published with permission from exaDevices
They had basically two options as I see it:
1. Revise the I2S specifications for proper operation.
2. Revise the I2S specifications in a quick and dirty fashion and allow for easy operation of 16 - 32 bit transmitters and 16 - 32 bit receivers at the cost of accuracy..
They selected option 2 and if these I2S specifications are followed the true fidelity are compromised.
I was for many years able to avoid the problems by only playing 16 bit sources and only use pure 16 bit DAC´s as this is the only combination that avoids the I2S specifications errors.
With 24 bit sources and 24 bit DAC´s and 32 bit sources and 32 bit DAC´s the problems are also avoided.
But to be able to play 16 - 32 bit sources with a 32 bit DAC as the ES9018 the sender side needs to correct the I2S specifications errors for bit depths between 16 and 32 bit.
Due to most music are available as 16 and 24 bit the correction can be implemented in 8 bit steps..
exa065 / exaDevices developed a version of the ASIO driver that implemented the correction options after my request.
As they do NOT use a general available ASIO driver, but have developed their own ASIO compliant driver that have full control from the player application to the registers in the DAC they could implement my requested changes at once.
A exaU2I Configuration Tool to manually change the setup was made for the beta testing and measurements in a controlled environment.
This exaU2I Configuration Tool are not available to the public as the ASIO driver now have included a check box for selection of the automatic LSB extensions corrections.
Screenshoots of both the exaU2I Configuration Tool and the ASIO driver configuration screen are attached.
In the finalized version the automatic LSB extensions (when selected) requires a bitperfect source.
If the volume control or any other manipulations are used (DLL´s, pluggins etc.) the LSB extensions corrections are automatically turned off as it will only work as intended with bitperfect sources.
The screenshoots are from the latest versions of the Configuration Tool and ASIO driver.
The updated ASIO driver will be available from exaDevices as soon as they have finished the quality controls.
I have been using a SDTrans192 SD card player as my primary audio source for a period of time and also this device have implemented the automatic LSB extensions.
The firmware (SDTrans192) was first done as a paid job exclusively for me, but became a standard of the SDTrans192 later.
When the users of exaU2I have installed this new updated driver there are very easy to check or uncheck the automatic conditional LSB extensions in the ASIO driver configuration panel as shown in the attached screenshots.
For those that wonders if there are any improvements in the fidelity the answers are simply yes.
Most of the harsh "digitalis" distortions are removed and everything in respect of fidelity improves.
I expect there will be posted reports as the exaU2I users have installed their devices and upgraded the ASIO drivers..
When working with exa065 on the new ASIO drivers I became aware of the fact that when the exaU2I are configured as a 2 channel device the L & R channel are repeated on the three remaining I2S channels.
This makes it very easy to connect a ES9018 DAC as there is no need of tweaking with register settings to utilize the ES9018 as a 2 channel device...
Published with permission from exaDevices
Attachments
Last edited:
Soundcheck,
It appears that you participate in this thread to distract people form the good news coming from exaDevices.com. SunRa just confirmed a second DAC running at 352.8 kHz. This is quite big.
Here is what people are saying to me in private emails:
"I believe you have a truly excellent product. I'm now shuffling my audio files and enjoying the music. .... Thank you again for making this possible, really! Oh, and by the way, the interface and drivers seem rock-solid"
"Thank you for developing a DXD-usb interface for the masses."
"By taking the lead you have stirred the calmness that have been in the market for a couple of years"
The standards have become a constraining factor. The real world is so far ahead that even small companies are capable of innovation. exaU2I is the new standard for affordable performance.
What kind of answer is that?
I do think I got a point here. Wouldn't be the first FPGA taking care on a little data mangling.
Following your logic, that wouldn't require a proprietary ASIO driver
anymore and exadevices could comply to standards. If they would have chosen a more standard interface chip. And if Windows would
finally deliver an acceptable usb-audio driver. (If you're still close connected to Microsoft - you maybe got some influence.
) Buying an exa USB device:
Man, I'm blacklisted at the company now. Even if I would consider to buy ...
To be honest. I'm looking for a multichannel USB interface.
That's why I'm sneaking around here. Currently I see too many compromises popping up here and there with this solution.
I'm looking for a headless client doing the processing and feeding a multichannel device somewhere in the network.
What do you mean? ...I can't believe it.
Am I undermining your marketing campaign?
This is the wrong forum to do commercial marketing, man!!!! Didn't know that?
Can't be the case. I skip to quote that comment made earlier by someone else.
I hope your latest post is going to trigger any moderator to move this
thread finally over to the vendor section.
I think you need to take into account that this product suits the needs of many Windows users that want a multi channel setup running off USB. Sure it means exa will have to provide driver support, but provided things are functional now under the Windows 7 interface there are years of usage ahead for people.
By the way I neither own the unit nor do i have vested interests in anyone else's kits. I'm looking at buying something like this though when the situation allows.
By the way I neither own the unit nor do i have vested interests in anyone else's kits. I'm looking at buying something like this though when the situation allows.
When the exaU2I have finished OSX drivers you can have your solution with Pure Music / iTunes..
You get automatic sample rate switching or upsampling (integer and 64bit processing), native FLAC support, iPad or iPhone og MacBook as remote, up to 4 way crossover (advanced with 64bit processing)...
I uses this solution (today with M2Tech USB -> I2S) and the only issues I have are the ever changing "bugs" in iTunes
Due to I have a large selection of DXD master files and also uses WAV, AIFF, FLAC I am stuck with iTunes 10.1.2 for the time being.
In iTunes 10.1.2 there are support for tagging and cover art with DXD / WAV
Versions before 10.1 and after 10.1.2 do not have this feature.
RayCTech,
just wanted to thank you for sending me to the right direction. I installed the Pure Music software and it works great. And yes I found crossover as well. It is not as powerful as Allocator, but it does the job. I will just transfer all the settings from Allocator to crossover and to parametric EQ and that will be it. And the comfort of MAC... and remote app on iPad...
I tried it before, but briefly and did not like the fact that FLAC files are converted, but I was wrong I realized after your explanation and after I installed it this weekend. They are not converted.
I see you are running Hackintosh, ha, ha. Isn't that amazing? I am still just plain amazed, when I pull my MacBookPro and run Windows XP and Sound Easy for speaker measurement... I still laugh when I do that. Macs were always from a different planet, even in System 7 days, but with OSX... and Intel chip... it is just hard to believe.
Thank you very much for the advice and your help
AR2
Hello all,
I have an update regarding my hiss problem with higher sampling rate material.
So here's a brief of the problem:
A. Original Beethoven 352.8K / 24 bits file from 2L HD website - hiss
B. Original Bizet's Carmen 352.8K / 32 bits floating point (forgot the source) - no hiss
C. Any other 24bits / 192k and below files - no hiss
So I did an experiment. I took the original Beethoven 352.8k / 24 bit file from 2L HD and converted it. The results are the following:
1. converted to 32 bit / 352.8k, floating point - hiss
2. converted to 32 bit / 352.8k, integer - hiss
3. down-sampled to 192k, 24 bits - no hiss
My thinking hat is not serving me very well so if you have any ideas, you are welcomed
edit: Also I mention again that I get no hiss with any 24bits / <192Khz files. Just the 352.8k / 24 bit files from 2L HD when I try to play them as they are.
I have an update regarding my hiss problem with higher sampling rate material.
So here's a brief of the problem:
A. Original Beethoven 352.8K / 24 bits file from 2L HD website - hiss
B. Original Bizet's Carmen 352.8K / 32 bits floating point (forgot the source) - no hiss
C. Any other 24bits / 192k and below files - no hiss
So I did an experiment. I took the original Beethoven 352.8k / 24 bit file from 2L HD and converted it. The results are the following:
1. converted to 32 bit / 352.8k, floating point - hiss
2. converted to 32 bit / 352.8k, integer - hiss
3. down-sampled to 192k, 24 bits - no hiss
My thinking hat is not serving me very well so if you have any ideas, you are welcomed
edit: Also I mention again that I get no hiss with any 24bits / <192Khz files. Just the 352.8k / 24 bit files from 2L HD when I try to play them as they are.
Last edited:
Hello all,
I have an update regarding my hiss problem with higher sampling rate material.
So here's a brief of the problem:
A. Original Beethoven 352.8K / 24 bits file from 2L HD website - hiss
B. Original Bizet's Carmen 352.8K / 32 bits floating point (forgot the source) - no hiss
C. Any other 24bits / 192k and below files - no hiss
So I did an experiment. I took the original Beethoven 352.8k / 24 bit file from 2L HD and converted it. The results are the following:
1. converted to 32 bit / 352.8k, floating point - hiss
2. converted to 32 bit / 352.8k, integer - hiss
3. down-sampled to 192k, 24 bits - no hiss
My thinking hat is not serving me very well so if you have any ideas, you are welcomed
edit: Also I mention again that I get no hiss with any 24bits / <192Khz files. Just the 352.8k / 24 bit files from 2L HD when I try to play them as they are.
There are maybe some tweaks you can try..
They may not improve anything, but here they are:
1. Check the input format MSB justified.
2. Check what happens with DFS0 and DFS1 = "1".
3. Test the slow rolloff filter function.
4. Increase the DVDD and AVDD (and voltage to the GMR´s on the exaU2I) to 5.5 volt or 6 volt...
5. Test a master clock at 45.1584MHz (41.472MHz are maximum "supported"...).
If you test point 4 and 5 you may need cooling of the chip (like I have in the pictures of the exaU2I in a previous post)..
I could not find any information of how to turn of or change the 8x interpolation filter, but this would have been the correct way to do it...
Maybe you have the only one
Hi NicMac,
As a experienced Buffalo user you may consider the exaU2I or are you waiting for the TPA USB product to be designed?
Thanks RayCtech, much appreciated,
What effect should (4) have? I thought this is only in the case I want to use ak4396 with CMOS, not TTL levels. Changing the master clock (5), or the roll-off filter function (3) doesn't solve the fact that I have two 352.8k files at 32 bits playing perfectly fine, while the diethered (24 to 32bit) 352.8k are still presenting the hiss.
Regarding (1) and (2), the I2S format inputs. Isn't this only a hardware standard? I mean, can a certain PCM format generate a change in the I2S format outputed by the fpga?
Before starting to change the settings of the DAC, I would like to convert a bit these files. If you you know a free sample rate converter capable of upsampling to 352.8k, 32 bits, let me know please. The web is probably full of them but they don't have specs and I wouldn't want downloading them all. I've played with R8brain and AbyssMedia Audio Converter Plus, none of them being able to reach that sampling rate. They can convert to 32bits, with no effect though.
Also do you know where can I find the exact specs of the DXD format? Can't find them anywhere and I have the feeling this is the catch. That is, I believe that upsampled 176Khz files to 352k should play without a hiss, and the dxd files from 2L HD are encoded differently. This would explain why changing their sample rate to 192Khz allows correct playback - they are simply converted to a standard PCM file.
What effect should (4) have? I thought this is only in the case I want to use ak4396 with CMOS, not TTL levels. Changing the master clock (5), or the roll-off filter function (3) doesn't solve the fact that I have two 352.8k files at 32 bits playing perfectly fine, while the diethered (24 to 32bit) 352.8k are still presenting the hiss.
Regarding (1) and (2), the I2S format inputs. Isn't this only a hardware standard? I mean, can a certain PCM format generate a change in the I2S format outputed by the fpga?
Before starting to change the settings of the DAC, I would like to convert a bit these files. If you you know a free sample rate converter capable of upsampling to 352.8k, 32 bits, let me know please. The web is probably full of them but they don't have specs and I wouldn't want downloading them all. I've played with R8brain and AbyssMedia Audio Converter Plus, none of them being able to reach that sampling rate. They can convert to 32bits, with no effect though.
Also do you know where can I find the exact specs of the DXD format? Can't find them anywhere and I have the feeling this is the catch. That is, I believe that upsampled 176Khz files to 352k should play without a hiss, and the dxd files from 2L HD are encoded differently. This would explain why changing their sample rate to 192Khz allows correct playback - they are simply converted to a standard PCM file.
Ok so I am back with more details.
I've converted a 176Khz file to 352.8k and it plays just fine, no hiss.
I've converted one of the 352.8k /24bits files to 176k/24 bits and then back to 352.8k and again, no hiss.
Conclusions:
There's something odd with DXD. Simple conversion of 24bits to 32 bits is of no effect. Sample rate conversion changes something in the coding of these files.
I've converted a 176Khz file to 352.8k and it plays just fine, no hiss.
I've converted one of the 352.8k /24bits files to 176k/24 bits and then back to 352.8k and again, no hiss.
Conclusions:
There's something odd with DXD. Simple conversion of 24bits to 32 bits is of no effect. Sample rate conversion changes something in the coding of these files.
The hiss could be a result of some parts of the DAC that runs with to high clocks / samplerate or simply the master clock are to low and there are not enough headroom in one of the stages or some of the stages are slightly to slow..
4. Should incease the current and thus the speed of all stages.
2. Could possibly reduce the oversampling by 0.5 if it works.
PM sent with converters info.
DXD are straight signed two´s compliment code and nothing special, only the file header have some values that identifies the file type etc..
The 2L DXD files are coded correctly as I have the DXD masters of the 23 albums 2L have recorded until now...
Something strange must happen in the player or the DAC when you play the floating point files..
I will convert one DXD file to 352.8k/32bit floating point and check what happens when played with Foobar2000, J.River, iTunes and Pure Music.
Hmmm... Your last post was interesting...
I must check this by running one DXD through the converter and check what happens..
Last edited:
This doesn't explain why the Bizet Carmen 352.8k / 32 bits is playing without a problem, as well as another file coming from the same source also at these sampling rates and resolution.
And also doesn't explain why a 176khz file, upsampled to 352.8k also plays perfectly way.
I am at this point absolutely sure that this is not a hardware problem of the DAC. However it is not exclusive to the DXD files as you told me you dont't have any problem playing them with the ESS dac.
It's the interaction of these specific DXD files with the interface and the DAC.
I have considered it and my reasons for not getting it are:
1) I'm a Mac only user.
2) I have no use for 8-channel capability.
3) The price-tag is steep (say 100$ to high).
4) The lack of independent reviews.
5) Other very good (and cheaper) dedicated 32-bit USB-I2S (stereo) transports have recently become available.
6) I have only been able to get my hands on one piece of true 32-bit music...
7) Although exaU2I might be unique at this moment in time I'm convinced that in just a few months there will be very serious competitors that will push the price down and the quality up.
Just about the only TPA product that I'm not waiting for is the USB module as I believe it will be almost identical to another device I already posses.
Cheers,
Nic
The only event that will push price down is more production quantity. Making one custom electronic device is incredibly expensive. You have to make at least 100 to get the first discounts, but usually it's not enough to reach a 'fair' retail price until you make 1000. I doubt that there are even 100 people willing to build their own DAC. I could be wrong about the number of people interested, but I'm not wrong about the costs. Making 100 different products doesn't save any money - you have to have 100 people agree on the same platform and then you get discounted prices.
Quality might be pushed up by competition, especially with a forum like diyAudio to discuss what is learned by each new attempt.