Windows 7 x64 keeps forgetting my USB DAC's abilities

Nazo

2[H]4U
Joined
Apr 2, 2002
Messages
3,672
So this is kind of a strange one. I recently reinstalled Windows 7 x64 because I wanted to switch over to UEFI (I was using CSM before and converting without using commercial software is quite a lot harder than you might think so I eventually just gave up) and it was getting a bit bogged down over time anyway. Now, nothing has changed. Exact same hardware, same software, same updates, etc etc. But for some odd reason Windows keeps deciding this USB DAC can only do 44100Hz or 48000Hz at 16-bits and absolutely nothing else. (For the record it is capable of 24/192.) I have to "uninstall" the device from device manager and tell it to delete the drivers then reinstall drivers about 15 times to get it to suddenly recognize that it is capable of more. Weirder still, it's the same drivers I used before... But then it will forget after a reboot or two (I think three is the most it ever survived.) Then once again I have to repeat the process to get it to accept that the device is capable of more. To be clear, I didn't have this problem before the reinstallation. Windows 100% understood its capabilities and never once "forgot."

I'm getting really tired of having to manually fix this and would really like a more permanent solution. Given the weirdness of this whole issue I have no clue what could even be the cause. Everything is the same including software and drivers, so there's just no explanation that makes any sense. It's not even the hardware itself because A. it worked just fine before, B. this isn't the kind of thing that failing hardware would do (even if it were old which it is not,) and C. it works fine outside of Windows in Linux or whatever. I've even used it on an Android phone with no problems getting its full capabilities (though sadly my current phone isn't working with OTG.)

Actually, with the way it "forgets" I almost wonder if it's something like Windows tries to query the device but it doesn't answer fast enough and Windows just falls back to a "safe" default or something. Might there perhaps be some way to bypass this or something if that is the case?


EDIT: Never got it to properly work on that system. As far as I can tell what it comes down to is the newer drivers just didn't get along. Unfortunately, I really didn't know what older drivers to use. I suppose someone with the patience to do it could just go through older driver archives until they found some that didn't have the problem. Since I was already planning on upgrading my system it didn't seem worth doing all that. I have since upgraded and the new system doesn't have this problem (in no small part due to only having one chipset to deal with.)
 
Last edited:
So this is kind of a strange one. I recently reinstalled Windows 7 x64 because I wanted to switch over to UEFI (I was using CSM before and converting without using commercial software is quite a lot harder than you might think so I eventually just gave up) and it was getting a bit bogged down over time anyway. Now, nothing has changed. Exact same hardware, same software, same updates, etc etc. But for some odd reason Windows keeps deciding this USB DAC can only do 44100Hz or 48000Hz at 16-bits and absolutely nothing else. (For the record it is capable of 24/192.) I have to "uninstall" the device from device manager and tell it to delete the drivers then reinstall drivers about 15 times to get it to suddenly recognize that it is capable of more. Weirder still, it's the same drivers I used before... But then it will forget after a reboot or two (I think three is the most it ever survived.) Then once again I have to repeat the process to get it to accept that the device is capable of more. To be clear, I didn't have this problem before the reinstallation. Windows 100% understood its capabilities and never once "forgot."

I'm getting really tired of having to manually fix this and would really like a more permanent solution. Given the weirdness of this whole issue I have no clue what could even be the cause. Everything is the same including software and drivers, so there's just no explanation that makes any sense. It's not even the hardware itself because A. it worked just fine before, B. this isn't the kind of thing that failing hardware would do (even if it were old which it is not,) and C. it works fine outside of Windows in Linux or whatever. I've even used it on an Android phone with no problems getting its full capabilities (though sadly my current phone isn't working with OTG.)

Actually, with the way it "forgets" I almost wonder if it's something like Windows tries to query the device but it doesn't answer fast enough and Windows just falls back to a "safe" default or something. Might there perhaps be some way to bypass this or something if that is the case?

It actually sounds like the drivers may be loading before the device is recognized by Windows, therefore for some odd reason Windows applies it's own 'defaults'? So either you have to try and slow down the loading of the driver or figure out where Windows is pulling these defaults from.
 
How would drivers load before the device is detected? As far as I know Windows does it the other way around. Regardless, I don't think Windows has any mechanism to slow that part down. Changing the defaults seems like the only realistic possibility there anyway, but I have no idea how I'm supposed to find that if it even can be changed.
 
How would drivers load before the device is detected? As far as I know Windows does it the other way around. Regardless, I don't think Windows has any mechanism to slow that part down. Changing the defaults seems like the only realistic possibility there anyway, but I have no idea how I'm supposed to find that if it even can be changed.

Audio under Windows does some very weird and wonderful things at times. Why does my daughter's PC keep detecting her microphone as a pair of headphones running Realtek audio? It even does it without rebooting the machine! I have no idea. All I know is that it's very annoying having to unplug...Wait....Plug the microphone back in....Wait for it to be detected and select it as 'Mic In' time and time again.

Have you checked Event Viewer to see what's reported in the log files? Perhaps try Reliability Monitor as well?

Are you actually shutting the PC down or putting it to sleep/some form of Hibernation?
 
Hmm. There is a warning in the event viewer that says Kernel-PnP, the driver \Driver\CMUAC failed to load for the device which matches the device hardwareid. It provides exactly zero details however. My system is Prime95 stable though (and with my hardware setup it would be difficult for it to go unstable in normal use anyway -- I design around a balance of efficiency and effectiveness, so it's a low power chip that runs very very cool and just for instance my CPU is at 25C right now,) so it's not an issue of stability. I have no idea what I'm supposed to do with that information, but I guess it does confirm the driver fails to load and it falls back on some default it's not supposed to be using.

BTW, your issue is a bit different. Possibly really simple. RealTek has most of their onboard chipsets and actual soundcards built around their chipsets designed to be able to reroute any audio port to any task. It's supposed to pop up a dialog box asking which to assign a particular device when you plug it in. Obviously it's just falling back on the default which is a standard audio output. But perhaps if you make sure to plug into the pink port it will default to microphone, saving you the trouble of reassigning? My problem is almost sort of the opposite. Where you're seeing over-complex drivers, this is as simple as it gets. This just simply establishes a single output device, its capabilities, and absolutely nothing else. (It doesn't even have any input at all and only one output.) There is no ability to reroute anything or anything like that. (As a bit of a key point I'm using minimal drivers. Though in this case I don't think there are bloaty drivers available for this one anyway. It's a super simple CMedia CM6631A USB interface -- the Schiit Modi 2 Uber to be specific.) Actually, to quote Schiit: "Again, Windows requires drivers. Alert to Microsoft: USB Audio Class 2 was, like, a decade ago. Please support it and stop requiring us to provide drivers. Seriously, Android phones support it." The drivers almost don't do anything at all in this case and it's ridiculous they're even needed.
 
BTW, your issue is a bit different. Possibly really simple. RealTek has most of their onboard chipsets and actual soundcards built around their chipsets designed to be able to reroute any audio port to any task. It's supposed to pop up a dialog box asking which to assign a particular device when you plug it in. Obviously it's just falling back on the default which is a standard audio output. But perhaps if you make sure to plug into the pink port it will default to microphone, saving you the trouble of reassigning?

The problem is, the PC is an Intel NUC that only has one 'universal' jack port for both input and output. I use Intel HD audio via HDMI for audio out and want the Realtek drivers to permanently assign the Jack port to Mic In - But that seems impossible to do.

Hmm. There is a warning in the event viewer that says Kernel-PnP, the driver \Driver\CMUAC failed to load for the device which matches the device hardwareid.

I think the driver is loading before your device is detected via USB.
 
The problem is, the PC is an Intel NUC that only has one 'universal' jack port for both input and output. I use Intel HD audio via HDMI for audio out and want the Realtek drivers to permanently assign the Jack port to Mic In - But that seems impossible to do.
Unfortunately, yeah. Unless you can find some way to modify the default setting itself. But anyway, at least it's not too hard to understand the nature of the problem. Best I can tell you is make sure the drivers are set to ask upon detecting a device plugged in or leave it plugged in all the time. (Or get really lazy and use a USB microphone device, lol.)

I think the driver is loading before your device is detected via USB.
I don't know, it sounds almost like this says the opposite to me. It shouldn't even try to load the driver if it doesn't see any reason to load it. I'm pretty sure this means it's definitely seeing the device and trying to load the driver, but something fails along the way. Actually, perhaps I forgot to mention, but I can remove it from the device manager (checking the "delete driver files" option to be extra sure) and when I refresh it it detects it as a driver-less device (maybe worth noting it always has the correct name for the device at all times even when the drivers are not loaded and it doesn't work.) If I reinstall the drivers, at least nine times out of ten it will still have the limited capabilities (I'm still not clear on if I have to reboot to fix it. The whole thing seems so random.) Worse than that I think. If it were, as you say, drivers loading before the device is detected then when I manually load the drivers afterwards it should work, but most of the time it does not.

I was yet again on 44/16 and 48/16 being the only options when I wrote that post. I once again force removed and reloaded the drivers and once again I'm back to its full capabilities. I checked the CMUAC.SYS file from before (I renamed it) and the MD5 sum matches exactly with the CMUAC.SYS file from the drivers. So the file has not changed.
 
I had/have a Line 6 Audio device that never worked properly under windows. Sometimes it would boot sometimes it wouldn't, windows would drop it all the time... or completely hang the entire audio system. At first I blamed Line 6 but then I realized its an issue with all USB audio... cause MS. My Line6 just works under Linux but whatever.

Maz I believe is onto perhaps a fix.

I took a bit of time and grabbed a copy of the windows 7 driver for a CMedia CM6631A. I'm not sure if its the same driver your using or not... but pop up your drivers .inf file and see if your version has bits in it.

[CMUSBDAC.ServiceInstall]
DisplayName=%CMUSBDAC.DeviceDesc%
ServiceType=%SERVICE_KERNEL_DRIVER%
StartType=%SERVICE_DEMAND_START%
ErrorControl=%SERVICE_ERROR_NORMAL%
ServiceBinary=%12%\CMUSBDAC.sys

Looking at this it shouldn't be starting before the USB drivers... its listed as a kernel level driver but with on demand start it should be starting after core things like USB... however perhaps try the opposite road and force it to start sooner.

You could try changing that to SERVICE_AUTO_START or SERVICE_SYSTEM_START... no idea if SERVICE_BOOT_START is a good idea. I think you can fine the inf in driver store ? (sorry not a big windows person anymore, its been awhile since I went through much windows stuff myself) or just reinstalling ? (as it sounds you have done that a bunch anyway lol) I don't know worth a try. (of course I think you can select most of these from the service manager and I'm sure you tried all that already... only one you can force I think is the boot start option)

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/specifying-driver-load-order
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/inf-addservice-directive
 
Last edited:
Hmm. I went ahead and tried editing the INF file, though that won't apply at this time obviously. I searched through the registry until I found the CMUAC service and CurrentControlSet has it set to 1 (system.) ControlSet001 and ControlSet002 have it set to 3 (manual.) This might be meaningful. For now I set the other two to 1 as well.

EDIT: Well, it survived at least one reboot anyway.
 
  • Like
Reactions: ChadD
like this
Hmm. I went ahead and tried editing the INF file, though that won't apply at this time obviously. I searched through the registry until I found the CMUAC service and CurrentControlSet has it set to 1 (system.) ControlSet001 and ControlSet002 have it set to 3 (manual.) This might be meaningful. For now I set the other two to 1 as well.

EDIT: Well, it survived at least one reboot anyway.

Here's hoping. :)
 
So here's my theory: when set to manual it doesn't recognize it properly to manually start it. Under some circumstances, perhaps Windows uses ControlSet001 or 002 instead (though I've never told it to -- I've never even used the multi-configuration in Windows and I don't know anyone who really did) and once switched over it carries over to being current.

At least I have something to look for. I'll have to wait until (if) I reproduce the problem.
 
Fingers crossed my friend.

I might have to look into one of these USB microphone thingies you talk about!
 
I hate to derail my own thread, but I use this sort because I can clip it onto any pair of headphones (this Modi 2U powers a Sennheiser HD650, which is a lot better in every sort of quality than quite possibly any "headset" out there): https://www.amazon.com/dp/B074BLM973/ (The one I have is cheaper and lower quality, but it's virtually the same thing.) Typically Windows will switch to using whatever you've most recently plugged in as the default. Actually, given that you're using HDMI, you could probably just disable the RealTek entirely so that it will have only whatever is plugged in.
 
As an Amazon Associate, HardForum may earn from qualifying purchases.
I hate to derail my own thread, but I use this sort because I can clip it onto any pair of headphones (this Modi 2U powers a Sennheiser HD650, which is a lot better in every sort of quality than quite possibly any "headset" out there): https://www.amazon.com/dp/B074BLM973/ (The one I have is cheaper and lower quality, but it's virtually the same thing.) Typically Windows will switch to using whatever you've most recently plugged in as the default. Actually, given that you're using HDMI, you could probably just disable the RealTek entirely so that it will have only whatever is plugged in.

I'd love nothing more than to disable Realtek entirely. Their drivers are a PITA.

I'll look into it, thanks!
 
As an Amazon Associate, HardForum may earn from qualifying purchases.
Ok, today I booted up and the sound was gone entirely. The device manager said the drivers were unable to load. When I tried to reinstall using the INF modified to use the earlier startup it said it was "unable to start the driver." (No details. So useful!) net start cmuac in a command prompt said "system error 1058 has occurred. The service cannot be started, either because it is disabled or because it has no enabled devices associated with it."

Anyway, I physically unplugged the device (bit of a pain to actually do where I have it mounted) and plugged it back in. Suddenly it worked. In a way this is actually an improvement because now I know immediately when Windows has decided to screw up due to not having sound entirely. I still don't know why or have a proper reasonable fix though.
 
Anyway, I physically unplugged the device (bit of a pain to actually do where I have it mounted) and plugged it back in. Suddenly it worked. In a way this is actually an improvement because now I know immediately when Windows has decided to screw up due to not having sound entirely. I still don't know why or have a proper reasonable fix though.

Sort of what I have to keep doing, I don't have to even reboot for the Mic In to be switched for Line Out, all I have to do is sleep the PC. Every day, multiple times a day, I have to unplug that Mic and plug it back in making sure it's detected as a microphone and not a set of headphones.
 
Ok, today I booted up and the sound was gone entirely. The device manager said the drivers were unable to load. When I tried to reinstall using the INF modified to use the earlier startup it said it was "unable to start the driver." (No details. So useful!) net start cmuac in a command prompt said "system error 1058 has occurred. The service cannot be started, either because it is disabled or because it has no enabled devices associated with it."

Anyway, I physically unplugged the device (bit of a pain to actually do where I have it mounted) and plugged it back in. Suddenly it worked. In a way this is actually an improvement because now I know immediately when Windows has decided to screw up due to not having sound entirely. I still don't know why or have a proper reasonable fix though.
The modified inf couldn't be used because its catalog signature no longer matched the inf file's hash.

I've had similar issues to what you are describing, but caused by monitors (!). Though they're not supposed to do this, some models "reverse probe" the hdmi or displayport and then cause a pnp event when the monitor detects a system is booted. This can cause the hdmi/dp speaker path to be seen as the most recently plugged in, thus switching over to that as the default and screwing up your system's audio settings.
 
The modified inf couldn't be used because its catalog signature no longer matched the inf file's hash.
I have digital signature enforcement disabled for another thing (I forget which thing it was now, but not sound related.)

I've had similar issues to what you are describing, but caused by monitors (!). Though they're not supposed to do this, some models "reverse probe" the hdmi or displayport and then cause a pnp event when the monitor detects a system is booted. This can cause the hdmi/dp speaker path to be seen as the most recently plugged in, thus switching over to that as the default and screwing up your system's audio settings.
Well, no other sound device is taking over for sure. I have the HDMI audio options disabled entirely (I wish they'd stop adding them automatically without even asking the user during installation) so when this fails there is no audio device to take over at all in fact. It does seem like some sort of race condition is indeed occurring where something starts too late or too soon or something, but I have no clue how to actually find or fix the specifics.
 
out of curiosity does your board by chance have a power on/charging usb port? wonder if plugging the DAC into that might trick it into keep it on when going into windows so it instantly loads the device.
 
I don't think that would make a difference for one simple reason: Windows reinitializes all USB ports during startup and intentionally shuts everything off. Frankly it sucks and annoys me a lot because it switches my keyboard back to its default setting every time. Anyway, I think my MB can actually do that, but I have it turned off and want it off (when shut down properly it uses significantly less than one watt of energy right now.)

This particular USB DAC has an external power supply though anyway. The standard Modi 2 does not, but the "Uber" version is the model with optical and coaxial inputs. (I may actually have to give up and go back to that, but I really don't want to since this avoids all the issues of full sound drivers and such and just generally produces better all around quality.) It uses an external power supply out of necessity to be able to support those.

Worthy of note given the power discussion: it never stops working after a suspend. When I suspend and resume it's working upon powering back up.
 
Last edited:
To me, it sure sounds like the audio driver is booting before the device is seen, fails, and falls back to the generic audio driver (which is probably where it's getting 44.1/16 Khz from). If so, unplugging/replugging would almost certainly fix the issue, as that would force re-initialization.

Is it *just* a driver; no third party program that's starting up and maybe hosing up the works?
 
Is it *just* a driver; no third party program that's starting up and maybe hosing up the works?
You don't get more just driver than this. Here is the entire file layout of the full driver package I'm using right now:

.\cmuac.cat
.\CMUAC.inf
.\X64\CMCplExt.dll
.\X64CMEffectAPO.dll
.\X64\CMUAC.sys
(There's also a X86 folder with the 32-bit versions of the same files -- obviously not used on this system.)

I suspect it's not even really using CMCplExt and CMEffectAPO as this particular setup doesn't have "MS Effects" enabled and no actual control panel even exists. (I think they're just there for compatibility.) What it comes down to is this thing is basically just telling Windows to fully utilize standards that are already basically built in and just not being fully utilized because... Microsoft I guess.
 
Alright, I may have figured this out. I'm adding an update for the curious in this thread and, more importantly, in case anyone searches this later. So my motherboard is an older one, a socket FM2+ board which has been replaced by at least FM3 (but I think that too has been superseded by AM4 or whatever.) When I last reinstalled Windows I naturally tried to make sure I got the latest drivers. And, in fact, the manufacturer provides the standard AMD drivers complete with their standard installer rather than a rebranded/custom installer. However, it seems the latest drivers have an imperfect USB implementation. I started having issues where when I replugged the USB DAC Windows would pop up a message "this device can perform faster if you plug it into a USB 2.0 port" which was making me pretty suspicious that something was up. (It's worth noting I was plugging it into a USB 2 port, not USB 3. I know USB 3 is a lot trickier driver-wise than 2 by far. But 2 is not tricky at all and hasn't been in probably more than ten years which is why this is just so ridiculous.) That made me suspicious that something might be up with the USB drivers themselves. So I went to the motherboard manufacturer and grabbed their much older drivers (17.12 to be specific -- I think the driver I had managed to track down on AMD's site was 18.10 or something.) So far it's working so well I have sound on startup instead of having to replug the device every time. ... So far. My suspicion is it's the USB bus drivers themselves that weren't correctly initializing rather than the USB audio filter drivers, although it's strange that only this one thing struggled. (I guess it comes down to the built-in drivers not being very smart but only this one is a device where built-in drivers would utterly fail to correctly assume its capabilities and just fall back on a super basic default that is backwards compatible to devices that haven't even been made in >10 years.)

EDIT: False alarm. It worked across a number of reboots then did the same thing again. Though it does beg the question of it it truly overwrote all of the driver files or if it kept some.
 
Last edited:
OK! I think this is the final update. In case anyone is interested or searches and runs across this later, I think I've FINALLY figured this out. And whew it was a pain. So it seems my motherboard manufacturer elected to go with a VIA chipset for the USB 2 and 3 ports. However, the main chipset is AMD. I didn't notice, but when installing the chipset drivers it has USB options selected. I wasn't aware the motherboard went a different direction there and apparently neither was the AMD driver installer... It installs its USB drivers. They don't work 100% right and that's why I had to use SDIO to fill in the blanks before since I guess it was mostly falling back to just built in basic and incomplete USB functionality, but what they do is establish a few filters and such that cause -- you guessed it -- problems with the USB even once the actual proper drivers load. I completely removed the AMD chipset drivers and reinstalled them with only the required bits (SATA, SMBus, and the IOMMU null driver that may or may not truly be needed,) making very sure all USB options were deselected.

I may be wrong, but so far this has survived multiple days and countless reboots/shutdowns. Fingers crossed, but I think I really solved it properly this time. I just wish I had caught it sooner. This does mesh well with the fact that I didn't have the problem on the older install for the simple reason that they had given us different driver packages before. (Simply put, long after this thing was past official end of life they supported it a bit longer but only the bare minimum required and no more.) I kind of made things worse trying to get the AMD drivers that time before in fact since it was VIA all along. The irony is, if I look more carefully on the driver page they do provide proper USB drivers there. I just am used to "chipset" packaging all of that sort of thing together and didn't pay attention. Otherwise I would have noticed it saying VIA drivers there and realized right off the bat. I'm especially posting this update because it's distinctly possible there are other motherboards out there with a different chipsets for USB (or I imagine even some other components) versus the north/southbridge stuff.

EDIT: Still not 100% fixed. *Sigh* It works a lot better -- it seems that if I replug it a while later it works then -- but it still doesn't work right off.
 
Last edited:
I'm convinced that MS changed something with their audio drivers in the last few months. My audio device swaps from 7.1 to stereo to being flat-out disabled at complete random. That only just started about a month ago.
Looking at the Nvidia forums and some threads on AVS, it seems like that has been cropping up for more and more people.
 
Well, I'm not using the latest MS USB audio drivers unless the USB drivers from one of those chipset manufacturers replaces those too.

I think the problem might be the fact that this motherboard actually appears to have both. There's an AMD bus and a VIA bus. I think the two driver sets are fighting with each other over who gets to control the USB as a whole. Well, I was already planning on upgrading my system with my tax refund when it goes through. I guess presumably I won't have the same problem with a much newer motherboard where the USB chipset is presumably more properly setup and more properly supported. I'm probably just going to stop fighting with this at this point and put up with it a bit longer.
 
Back
Top