foobar2000 Tech Support Forum Rules

Please read foobar2000 Tech Support Forum Rules before posting and comply with all the points.Failure to provide all the information pointed out in the above document in your post is considered wasting other people's time and in extreme cases will lead to your topic getting locked without a reply.

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 LeftANALOG OUT 32-bit RightS/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 LeftS/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.

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.

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.

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.

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 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.

I was thinking that maybe somebody could make a "driver" with fixed CLSID that would load (or locate) the E-MU driver by its name? I don't know how to do it but that was my two cents. Perhaps someone could explain why it's impossible or how it could be done.

Then you could choose this new "driver" instead of EMU-driver and it would work although EMU's driver's CLSID changed.

QUOTE (yayacek @ Jun 29 2008, 15:25)

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

Because it's not Foobar which is broken, it's the driver and other apps.

In my experience ASIO4All is not an adequate substitute for the native E-MU ASIO drivers.

With the native drivers, E-MU 0404 USB can switch automatically the sampling rate according to the source material. With ASIO4All, if I have E-MU set to the wrong sampling rate, Foobar crashes and looses the driver settings.

With ASIO4All it is impossible to produce any output via SP/DIF. Therefore it is impossible to verify that ASIO4All can produce bit-perfect output with E-MU 0404 USB.