Hi,

I've been having a problem with Foobar 0.9.5 "forgetting" the ASIO config for my E-MU 0404 USB sound device when I shut down the system. I'm using the E-MU as a USB-to-S/PDIF converter to drive an external DAC. For whatever reason, S/PDIF only works with the E-MU 0404 USB when ASIO is used.

When I go into the ASIO virtual device editor, it looks like this initially:

ANALOG OUT 32-bit Left
ANALOG OUT 32-bit Right
S/PDIF OUT 32-bit <none>
S/PDIF OUT 32-bit <none>

I then change it to:

ANALOG OUT 32-bit <none>
ANALOG OUT 32-bit <none>
S/PDIF OUT 32-bit Left
S/PDIF OUT 32-bit Right

Then, in "output device" I choose "ASIO: ASIO E-MU 0404 | USB", and click the "Save All" button. This works fine, just as expected. I can play all supported files just fine.

Next, I reboot and try to use Foobar with this saved ASIO configuration. When I try to play a file, I get the message "Unrecoverable playback error: Requested ASIO driver not found". To fix this, I must go into the ASIO virtual device config and choose "Remove" for the displayed E-MU 0404 USB. Before removal, the text of the device name is still shown, but the driver is somehow not recognized. Next, I add the configuration back in using the "Add New" button, then re-do the configuration process as I've described above, assigning Left and Right to the two S/PDIF logical outputs. Once I do this, my files play just fine again. However, this means I must go through this procedure each time I run Foobar from a freshly-rebooted system.

Any help with this would be greatly appreciated!

I just wanted to add that I just now saw that 0.9.5.1 was released. I installed 0.9.5.1 and the problem still occurs.

Error 0404: device not found?

My 0404 usb also lose its ASIO settings after reboot.
And... as far as I know, all 0404usb users have this problem, don't know whether the problem is in foobar2000 or e-mu, but in other applications (wavelab, cubase) the config is remembered.

Similar situation here. WinAmp and JRiver both remember the ASIO config after re-boot.

Same problem here, this is very annoying and probably a foobar ASIO bug.
There's the lost settings problem and the huge lag (a few seconds) when hitting stop, play etc.

known issue with all 0.9x versions + Emu 0404

The driver re-registers itself with a different class ID on each reboot. Apparently other apps remember ASIO drivers by name not by ID but it's a driver bug regardless IMO.

Is there any quick workaround you could implement or is it too much trouble ? I ask because this card is very popular with foobar users...

Somebody should mail e-mu and report back what they have said.
I'm too lazy for formal mails...


edit: Anyway, I've sent an e-mail to the tech support. Waiting for an answer...

Well, I got curious about this, so I downloaded the ASIO SDK from Steinberg to have a look at it. One thing I noticed is that although the individual functions that make up the API are reasonably well documented, there doesn't seem to be any sort of specification that lays out what is legal and what is not when the API alone is not enough to determine this.

Their driver example in asiosmpl.cpp uses a CLSID that's fixed at compile time and never changes, but is this a requirement?

If you look at their application example hostsample.cpp, the first function called by main() is loadAsioDriver(), whose argument is the driver name, not its CLSID. This then calls AsioDrivers::loadDriver() in asiodrivers.cpp, which in turn calls into its base class AsioDriverList::asioOpenDriver() in asiolist.cpp. It's not until that point that the CLSID is retrieved and passed to CoCreateInstance() to create the COM object.

So on the one hand, Steinberg do not specify what is "legal" to do vis-a-vis whether or not the CLSID is allowed to change. On the other hand, for the C++ helper class provided by Steinberg for exactly the purpose of loading the driver, the non-constant nature of the E-MU 0404 CLSID is a non-problem. If the code provided by Steinberg for this purpose were used, it would not be a problem in Foobar2000.

It would really be nice if a future version of Foobar2000 would use the same technique for loading the driver that's specified in the Steinberg example code.

The whole point of CLSIDs is being able to identify registered COM servers without relying on their names and such.

It would be even nicer if future versions of E-MU drivers stopped pretending that we have an entirely new driver registered each time the system starts.

It seems that there is a potential problem with multiple instances though, and that ASIO doesn't implement all the COM interfaces necessary to make that happen without "extracurricular" stuff going on. Since CoCreateInstance() isn't meant for multiple instances, this is leaving a lot of possibility for ambiguity. Looks like E-MU is working around the multiple instance issue with the dynamically-created CLSIDs.

It doesn't sound like this is going to be resolved anytime soon. I'll send an email to E-MU to see what they have to say about it.

The ASIO specification says that if you have multiple device instances handled by the same driver, they should be presented as different channel groups - which is the main reason why foobar2000's ASIO component requires you to set up "virtual ASIO devices" before using it. If other software can't deal with that, somebody needs to read the specification more carefully.

The problem still exist. Is there any chance to solve that annoying problem?

I'd like to say that very simply player XMPlay can keep ASIO setting so why Foobar cannot