0

It might help understanding what I'm trying to do in order to contextualize my question, so here goes.

I'm trying to hack the realtek sound jacks on my mobo to have the front audio stream routed out both the back panel's green and black jacks. Realtek drivers, or windows itself has really messed up quadrophonic audio, and speaker fill, so this is the only way to go for getting music out both jacks on my setup.

To do this (based on info from around the web, such as here) all that's needed is to change the values associated with some registry keys. I followed the registry rabbit hole to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96C-E325-11CE-BFC1-08002BE10318}\00XX\Settings\DrvYYYY_DevType_YYYY_SSYYYYYYYY

and look for

"Pin14" = Front speakers (rear green)
"Pin15" = Rear speakers (rear black)

Pin15 has to be changed to

"04 00 00 00" = Front speakers

to source the same front speaker signal on both output jacks.

OK cool, right? only in theory... I can make these changes, but when I reboot to make them take effect I see in regedit that the values have been switched back to default.

I found one supposed solution that said to go to [...]\00XX\GlobalSettings and change ResetAudioFgOnStart to value 0. No luck on my system, still refreshes default pin values on reboot.

So, I conjured up an idea to change the registry and key permissions, with the idea of preventing the values reverting to default on reboot.

On the [...]\00XX key I disabled inheritance but converted the default inherited permissions to explicit permissions for this key and its child objects (and subkeys) so I could manipulate their access. I restricted write access, leaving read access available for all principals that were listed when inheritance was previously enabled (i.e. SYSTEM, CREATER OWNER, ALL APPLICATION PACKAGES, Users, Administrators...). I only left write access for administrators since it is the owner, and I obviously need to change the permissions to what I'd like them to be. I selected also 'replace all child object permissions...' to make sure those changes were recursive.

However, for whatever reason, after a reboot the default values are still loaded up, preventing my changes from taking effect. Maybe I should have revoked administrators write access after making my changes to the values, but before the reboot (was pretty sure i tried that too... but it was a couple days ago now I was fiddling with this)?

Why didn't my changes to the permissions of this key tree prevent the values from reverting on reboot?

Any ideas how to lock those values I want in the registry?

EDIT: uploaded screen capture of my registry settings (yes i whited out my user name, nsa is watching :p), after manually making changes myself to the registry value I'm working on. This shows all the deny permissions (for SYSTEM, CREATOR OWNER, ALL APPLICATION PACKAGES, each locking them out of set value, create subkey, notify, create linnk, delete, write dac, write owner actions) included to prevent not just write access, but lock out the permissions for everyone but administrators group. Still, the value gets reset to the default once rebooted. Maybe the administrators group is the culprit, I doubt it since a popup would be expected to give administrators access for an operation, so I suspect it is a system process of sorts.

WELL can't post an image since I don't have 10 reputation, ugh... whatever, stupid internets, not like the post makes it sounds like I'm absolutely clueless

  • Did you check that's the only place in the registry that value needs to be changed? My guess is you missed one & that's the one 'in charge' at boot, overwriting your temporary Current Control Set value. – Tetsujin Sep 28 '14 at 6:17
  • The guide I linked to has worked for many people, obviously the latest drivers implement some changes causing it not to work for me. I'll try reverting to an earlier driver, but your comment is confusing... what do you mean a value 'in charge'? what process has permissions to overwrite what I've set? I'm interested in understanding the mechanics of windows registry that is allowing this to happen despite permissions I've implemented – brneuro Sep 28 '14 at 13:15
  • The CurrentControlSet is subservient to the numbered Control sets, depending on success or fail of recent boot attempts. I'm only guessing that one of them is overwriting the current set. I can't prove it because I don't have the same hardware setup. Try editing the same value in those other sets & see if it helps, or search for the registry key right through the entire registry & see if there might be other locations for it. Apart from that I'm not sure how you're going to lock out the system from writing to the registry... doesn't sound like a good move. – Tetsujin Sep 28 '14 at 13:38
  • OK, good do know about current control set being subservient to numbered control sets. However, no luck. I changed the value in both ControlSet001 (only numbered one) and CurrentControlSet, yet the both get switched back on reboot. At that, I also removed write/full control permissions for all users for the 0000\Settings\DRVxxx... key in both control set trees, and still they still revert at boot... i don't think changing permissions is a bad move as long as i only do it locally to these settings, what gives? – brneuro Sep 28 '14 at 14:06
  • Ah, pity... then I'm nearly out of ideas... Not something I've ever tried, but you'd have to lock perms for all processes except yourself, I think, on just those keys - it's not something I've ever even experimented with, so I've no idea of what would/should happen, sorry. – Tetsujin Sep 28 '14 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.