exaSound e18 - e20 - e28 - Info and Experiences Post All Here

[johndoe21ro]

Thanks for the review and the comparison, Stereolab. I wish you many amazing auditions with your new 'kids'.

[Audio_ELF]

I hope that from now on every DSD DAC will come with Mac ASIO drivers. DoP, after all, was just a pro tem solution for Mac computers.

DoP solves more than just Mac problems... People a lot cleverer than you or I worked on the problem to come up with the solution. I'm not saying it's the only solution but others have issues too!

 

To use ASIO for DSD every DAC manufacturer (or at least every USB interface design) requires custom written drivers. And remember 9 months ago we were all bemoaning every device who had chosen M2Tech interfaces for this very reason... How soon people forget!

 

The same hope over here. But ASIO drivers are ready for the Mac, thanks to George Klissarov. I believe are the music players developers that need to adopt them...!

Again; the exaSound ASIO drivers are only of use to those with an exaSound DAC. It may be possible to write a UAC2.0 complient ASIO driver but I am unsure if this would automatically support DSD except via DoP any more than the Core Audio driver does.

 

Things are not as simple/easy as you make out.

 

You should also not that ASIO drivers / software rely on another third party in the form of Steinberg so you are reliant on them as well as the player software and the DAC manufacturer for continued support.

 

I find it amazing how fickle people can be jumping on the latest bandwagon because one manufacturer announces it as the next big thing...

 

Eloise

[matthias]

DoP solves more than just Mac problems... People a lot cleverer than you or I worked on the problem to come up with the solution. I'm not saying it's the only solution but others have issues too!

To use ASIO for DSD every DAC manufacturer (or at least every USB interface design) requires custom written drivers. And remember 9 months ago we were all bemoaning every device who had chosen M2Tech interfaces for this very reason... How soon people forget!

Again; the exaSound ASIO drivers are only of use to those with an exaSound DAC. It may be possible to write a UAC2.0 complient ASIO driver but I am unsure if this would automatically support DSD except via DoP any more than the Core Audio driver does.

Things are not as simple/easy as you make out.

You should also not that ASIO drivers / software rely on another third party in the form of Steinberg so you are reliant on them as well as the player software and the DAC manufacturer for continued support.

I find it amazing how fickle people can be jumping on the latest bandwagon because one manufacturer announces it as the next big thing...

Eloise

 

ASIO DSD for OSX offers some advantages:

"True asynchronous operation. With Core Audio the Mac is always the master, the DAC works as a slave device. With ASIO the DAC is the master. (Which makes you wonder if that was the reason why ASIO was removed from OS X

Simple and reliable support for Integer and Exclusive Mode. ASIO always works in Exclusive Mode.

Improved performance - CPU load for native DSD is much lower compared to DoP. Older computers can play high-sampling rates DSD.

Improved reliability - DoP has to switch to PCM mode if a marker byte is lost.

Faster seamless transitions from PCM to DSD within the same playlist." (from the exasound homepage)

 

But the greatest advantage is that it sounds much better than DoP..............

 

Matt

[One and a half]

Which makes you wonder if that was the reason why ASIO was removed from OS X

 

Indeed, the same question can be asked for FLAC on the Apple platform. ASIO and the others were not made in Appleland, therefore don't belong in their AppleSillySystem.

[matthias]

I hope that from now on every DSD DAC will come with Mac ASIO drivers.

 

+1

 

Matt

[Mercman]

It goes beyond OSX. exaSound's Windows ASIO driver is able to play DSD directly without DoP.

[matthias]

It goes beyond OSX. exaSound's Windows ASIO driver is able to play DSD directly without DoP.

 

DoP has been created for OSX CoreAudio to play DSDoverPCM.

 

Matt

[Mercman]

For example; The MSB Tech ASIO driver requires that DoP be selected for use with JRiver in Windows:

 

http://www.msbtech.com/support/JRiver-19-Settings-Rev-2.pdf

[elcorso]

Intro

From the land of ice hockey, frozen wine, and decent beer, comes:

 

[ATTACH=CONFIG]14380[/ATTACH]

 

Two DACs manufactured by a small company in Canada called exaSound, run by a smart guy named George Klissarov. Both support PCM up to 32/384 and DSD up to DSD256 over USB. The e20 mkIII will run you $2499 and the e22 will run you $3499. exaSound also sells an 8-channel DAC called the e28, for $3849. See here for a spec comparison chart.

.

.

.

.

.

[ATTACH=CONFIG]14385[/ATTACH]

.

.

.

 

From a Mac user point o view:

 

Fully agree with your great review.

 

Mac ASIO drivers changed my opinion of what digital music can be improved versus Mac Core Audio, allowing DSD to be played as it should: out of DoP.

 

I have a Paul Hynes LPSU that make some improvements over the standard SPSU, but not heaven to earth. Thanks to exaSound power regulation:

 

"An external SMPS power supply with 11 power cleaning stages within the DAC. These multiple power cleaning stages allow every circuit to be powered separately with its own stage of power regulation. This feature prevents one power stage from modulating another stage helping to eliminate one source of DAC jitter."

 

My question goes to the "big" guys, if an "small company in Canada" can built ASIO drivers for the Mac, what are you waiting for?

 

Roch

[elcorso]

DoP solves more than just Mac problems... People a lot cleverer than you or I worked on the problem to come up with the solution. I'm not saying it's the only solution but others have issues too!

 

To use ASIO for DSD every DAC manufacturer (or at least every USB interface design) requires custom written drivers. And remember 9 months ago we were all bemoaning every device who had chosen M2Tech interfaces for this very reason... How soon people forget!

 

 

Again; the exaSound ASIO drivers are only of use to those with an exaSound DAC. It may be possible to write a UAC2.0 complient ASIO driver but I am unsure if this would automatically support DSD except via DoP any more than the Core Audio driver does.

 

Things are not as simple/easy as you make out.

 

You should also not that ASIO drivers / software rely on another third party in the form of Steinberg so you are reliant on them as well as the player software and the DAC manufacturer for continued support.

 

I find it amazing how fickle people can be jumping on the latest bandwagon because one manufacturer announces it as the next big thing...

 

Eloise

 

Good things are not always easy, but posible...

 

I didn't jump to the latest bandwagon (exaSound ASIO). I had exaSound DACs before ASIO. Even under Core Audio exaSound delivered a great SQ!

 

Please read my previous post in this thread.

 

Roch

[kennyb123]

I find it amazing how fickle people can be jumping on the latest bandwagon because one manufacturer announces it as the next big thing...

 

Latest bandwagon? ASIO has been around for many years on Windows. That it has now finally reached the Mac is certainly promising news. This is a hobby. Why shouldn't we get excited when we hear news like this? Kudos to exaSound for doing this. I hope other manufacturers jump on this too.

 

Direct Mode in A+ first revealed to me the benefits of bypassing Core Audio. That made it clear that Mac platform has long needed a standard way around this.

 

Mac users will benefit greatly if ASIO takes off. This is exactly the kind of bandwagon we should be jumping on.

[Miska]

You should also not that ASIO drivers / software rely on another third party in the form of Steinberg so you are reliant on them as well as the player software and the DAC manufacturer for continued support.

 

Apple doesn't seem to care if they break 3rd party CoreAudio drivers and player software on every OS release. While ASIO has been around since OS 9 / WinNT times (pre-OSX, mid-90's) and has been able to keep API and ABI compatibility for something like 15+ years already.

 

Problem with UAC2 is that it is over-bloated standard (typical designed by committee stuff) while being severely limited at the same time (no DSD support).

[bobusn]

Thank you, George, for the JRiver plugin (post #440)!

[Audio_ELF]

Indeed, the same question can be asked for FLAC on the Apple platform. ASIO and the others were not made in Appleland, therefore don't belong in their AppleSillySystem.

ASIO has been available on Apple with Steinberg software since before Mac OS X. It was only that, with the introduction of Core Audio, the majority of professional DAW software (the primary use for ASIO) have not felt the need to utilise ASIO or anything else.

 

DoP has been created for OSX CoreAudio to play DSDoverPCM.

Again ... DoP was NOT created for OS X. It was created (by dCS with others participating) to allow companies to utilise standard drivers while still supporting DSD.

 

Latest bandwagon? ASIO has been around for many years on Windows. That it has now finally reached the Mac is certainly promising news. This is a hobby. Why shouldn't we get excited when we hear news like this? Kudos to exaSound for doing this. I hope other manufacturers jump on this too.

The "latest bandwagon" is the fact that just because exaSound has created a ASIO driver for Mac, some people are acting like (a) EVERY manufacturer should produce such a driver and (b) it will cause a huge increase in sound quality. For (a) the majority of manufacturers do not have the expertise to do such a thing and rely on third parties for the USB interface and (b) while there may be a SQ improvement on the esaSound that does not automatically translate to other devices.

 

Mac users will benefit greatly if ASIO takes off. This is exactly the kind of bandwagon we should be jumping on.

That remains to be seen...

 

All I was originally commenting on is that there is also a downside to taking the drivers away from universal "built into the operating system" to putting them in the control of individual companies as users of M2Tech drivers found to their cost 9 months ago.

 

Eloise

[Audio_ELF]

Apple doesn't seem to care if they break 3rd party CoreAudio drivers and player software on every OS release. While ASIO has been around since OS 9 / WinNT times (pre-OSX, mid-90's) and has been able to keep API and ABI compatibility for something like 15+ years already.

 

Problem with UAC2 is that it is over-bloated standard (typical designed by committee stuff) while being severely limited at the same time (no DSD support).

No big company cares if they break 3rd party driver support. Microsoft is just as guilty of this in the past.

[Miska]

No big company cares if they break 3rd party driver support. Microsoft is just as guilty of this in the past.

 

Yes, luckily Microsoft doesn't release new OS versions as frequently as Apple. Those changes have not yet broken ASIO, but it may break some parts of the driver internal implementation though.

[Miska]

The "latest bandwagon" is the fact that just because exaSound has created a ASIO driver for Mac, some people are acting like (a) EVERY manufacturer should produce such a driver and (b) it will cause a huge increase in sound quality.

 

I think (a) is the case, (b) is a side effect. ASIO is good because it unties relation between available PCM and DSD sampling rates and it also makes it possible for player software to detect whether a DAC supports PCM or DSD. So it allows DACs that can only support PCM or DSD, or that support both. And user doesn't need to know about these details when using the player application.

 

If a DAC support 352.8/384 PCM rates and DSD256, with DoP it would need to support 705.6/768 PCM. User may not understand this and could try to play back 705.6/768 PCM and get strange results.

 

Another benefit is that with DoP you are running out of USB2 bandwidth at 8-channel DSD512 while with ASIO it still works fine. So it doesn't really scale well. Modern DACs support 32-bit PCM, so DoP has 50% overhead and thus half of the data transferred from computer is completely redundant.

 

As long as ASIO is not supported on Mac, you continue seeing DACs that can support DSD256/DSD512 on Windows through ASIO but don't make those available at all on Mac (iFi iDSD Nano/Micro and all DACs based on Amanero USB interface).

[Audio_ELF]

At the end of the day Miska most companies make the decisions which THEY find work best. As users we (okay not you as you are more on the manufacturer side) are second guessing those decisions. exaSound making a certain decision doesn't mean that same decision would be the best for dCS or Playback Design or iFi - that is what I'm trying to say.

 

If you want to support DSD256 and DSD512 then DoP is not a good solution and I understand that - but it's not entirely clear that supporting ever greater sample rates is necessary or desirable. (And no I'm not saying 16/44.1 is enough or anything close before anyone tries to out those words in my mouth!!!).

 

Eloise

[matthias]

At the end of the day Miska most companies make the decisions which THEY find work best. As users we (okay not you as you are more on the manufacturer side) are second guessing those decisions. exaSound making a certain decision doesn't mean that same decision would be the best for dCS or Playback Design or iFi - that is what I'm trying to say.

If you want to support DSD256 and DSD512 then DoP is not a good solution and I understand that - but it's not entirely clear that supporting ever greater sample rates is necessary or desirable. (And no I'm not saying 16/44.1 is enough or anything close before anyone tries to out those words in my mouth!!!).

Eloise

 

Exasound made an excellent decision and the same decision will be the best for all manufacturers that offer DSD DACs.

I want to repeat my post #360:

"When the customers see the advantages of ASIO for DSD256 and DSD512 they will put the pressure of competition on the companies. And Miskas comment gives hope:

Well, I'll put it this way... Let's say software player license costs average 100€. Software player has at least 1000 times more code than ASIO driver. So following the same logic people are ready to pay for software player licenses, ASIO driver would increase cost of the DAC by 0.1€. I think nobody would have issue paying such extra price, or even 10x whopping 1€ premium?

So the costs for ASIO are not high and the companies have some experiences with ASIO for Windows. IMO there is a bright future for ASIO for OSX."

 

Matt

[Miska]

If you want to support DSD256 and DSD512 then DoP is not a good solution and I understand that - but it's not entirely clear that supporting ever greater sample rates is necessary or desirable.

 

Your preferences are up to you to decide. Those rates are useful for DSD upsampling. Especially whenever you perform DSP on DSD it is better to upsample at the same time by at least 2x, because that way you gain extra headroom for any processing such as channel level adjustments on multichannel.

 

From my point of view, I'd prefer all the sampling rates being available on all platforms. DoP is just a hack to avoid working on a real DSD support.

[bmoura]

Exasound made an excellent decision and the same decision will be the best for all manufacturers that offer DSD DACs.

I want to repeat my post #360:

"When the customers see the advantages of ASIO for DSD256 and DSD512 they will put the pressure of competition on the companies. And Miskas comment gives hope:

Well, I'll put it this way... Let's say software player license costs average 100€. Software player has at least 1000 times more code than ASIO driver. So following the same logic people are ready to pay for software player licenses, ASIO driver would increase cost of the DAC by 0.1€. I think nobody would have issue paying such extra price, or even 10x whopping 1€ premium?

So the costs for ASIO are not high and the companies have some experiences with ASIO for Windows. IMO there is a bright future for ASIO for OSX."

 

Matt

 

The key will be customer interest and demand.

 

If other DAC makers see exaSound getting sales and purchases because exaSound made the investment and developed ASIO drivers while most other DAC makers have not, that can be a powerful motivation to add ASIO to current and future DSD DACs.

 

We will see what happens in the future.

[Stereolab42]

One thing to remember is that it's significantly harder to write good device/kernel level code (for example, a custom USB driver) than it is to write application code (for example, a software player). The environment is much more unforgiving, testing is hard, and the development kits and APIs are at best half-documented. There really aren't that many people with experience coding in this area. This is why almost nobody does it, and just buys prebaked drivers and control panels to talk to prebaked chipsets.

[Miska]

One thing to remember is that it's significantly harder to write good device/kernel level code (for example, a custom USB driver) than it is to write application code (for example, a software player). The environment is much more unforgiving, testing is hard, and the development kits and APIs are at best half-documented.

 

No, that is not true. I've been doing both drivers and application software. And I've spent most of my career in organizations doing both. If kernel device driver development APIs are poorly documented, then the OS itself shouldn't be regarded very high.

 

Windows has excellent documentation, best of all the three platforms I'm regularly working on. Linux is also well documented plus all source code is available (so you can do source level debugging of all parts). OS X is mediocre regardless if you want to develop drivers or applications. Documentation used to implement CoreAudio support to HQPlayer was OS X header files, nothing better was available.

 

I would say designing well performing (quality and speed) DSP algorithms is much more challenging than writing device drivers or GUI code.

 

 

P.S. As an example, hiFace Linux driver is around 900 lines total, while HQPlayer is way over 100000 lines total.

[Stereolab42]

Umm. I wrote (and still occasionally do write) Windows device drivers/kernel drivers for a living and while Microsoft's documentation was copious, it was far from complete. The lack of access to source code made it doubly hard to debug this or that interaction with kernel APIs or other drivers, so you had to have deep experience stepping through assembly. (I'm assuming you never had to debug power-management issues in Windows drivers, that was always fun.)

 

Anyways, I'm not comparing driver code to hand-optimized DSP routines, which I'm sure are no piece-of-cake. I'm comparing it to the 99% of application code that good kernel developers can crank out in their sleep at 10x the rate they can crank out kernel code. At least I can, speaking entirely modestly of course.

[Miska]

Umm. I wrote (and still occasionally do write) Windows device drivers/kernel drivers for a living and while Microsoft's documentation was copious, it was far from complete. The lack of access to source code made it doubly hard to debug this or that interaction with kernel APIs or other drivers, so you had to have deep experience stepping through assembly. (I'm assuming you never had to debug power-management issues in Windows drivers, that was always fun.)

 

Most companies anyway need to ship Windows drivers, because Windows still doesn't have a class driver for UAC2. USB device drivers are usually much less tricky because you just deal with existing USB APIs, instead of talking straight to hardware. Doing USB bus analysis is also quite a bit cheaper than PCI/PCIe bus analyzers.

 

Most challenging driver development I've done was for a custom PCI hardware where the PCI bridge chip documentation had a bit too many errors in it and the bridge chip had bunch of bugs for which errata didn't exist... You know, funny things happen when you busmaster-DMA transfers go wrong... I still completed the (Linux) driver in couple of months.

 

Anyways, I'm not comparing driver code to hand-optimized DSP routines, which I'm sure are no piece-of-cake. I'm comparing it to the 99% of application code that good kernel developers can crank out in their sleep at 10x the rate they can crank out kernel code. At least I can, speaking entirely modestly of course.

 

I know what you are talking about, I really dislike writing that kind of code, no challenge at all... Getting bored and upset too fast.