E-MU 0404 USB - foobar2000 "forgets" ASIO config on shutdown Options

[andy_c]

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!

This post has been edited by andy_c: Mar 25 2008, 23:40

[andy_c]

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.

[Canar]

Error 0404: device not found?

[volvme+]

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.

This post has been edited by volvme+: Mar 26 2008, 18:52

[andy_c]

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.

[bubbleguuum]

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.

[nightfishing]

known issue with all 0.9x versions + Emu 0404

[Peter]

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.

[bubbleguuum]

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

[volvme+]

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

This post has been edited by volvme+: Apr 25 2008, 18:15

[andy_c]

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.

[Peter]

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

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.

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.

[andy_c]

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.

[Peter]

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.

[volvme+]

Kristian,

Our support for audio players is limited, but I'll be more than happy to pass this information along for you! This may be considered low-priority, however.

Please remember the more information you provide, including previous correspondence in your mail, helps in troubleshooting and solving the problem you are experiencing.

Thank you,
-Tanner
E-MU Systems

[yayacek]

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

[mchaka]

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.

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.

[fanerman91]

So, is there a quick fix for this? Not-so-quick fix? Any kind of fix?

This post has been edited by fanerman91: Oct 20 2008, 03:32

[Fred de Nantes]

So, is there a quick fix for this? Not-so-quick fix? Any kind of fix?

I have a fix with ASIO4ALL setup like that, it works !



More informations, in french, here : http://ambiance-hifi.fr/viewtopic.php?p=77044

This post has been edited by Fred de Nantes: Nov 21 2008, 23:42

[George K]

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.

This post has been edited by George K: Jan 19 2009, 13:00

[Kohlrabi]

I have the same problem with a Creative Audigy 4 in Vista 64, using foobar 0.9.6 and foo_out_asio.dll version 1.2.6. Also installed the newest Creative drivers.

Additionally starting playback or switching tracks takes up to 3 seconds on some occassions.

All of this is probably bas driver support on Creative's end, but if someone knows a fix/workaround I'd be happy to know it.

[leeperry]

sorry to bump an old thread....but is this problem still present in the latest version?

[a3aan]

Yes.

sorry to bump an old thread....but is this problem still present in the latest version?

[yayacek]

Please explain!
The old Foobar 0.8.3 keeps ASIO settings perfectly (EMU-0404USB) so why the new version can't do it?

[Yirkha]

The driver can be trivially hacked to use the same CLSID every time.
If I had this sound card, I'd do it that way.
And I've seen some other guy successfully doing that in #foobar2000 too.
Just FYI.