Open jimmyvanhest opened 3 years ago
After thinking a bit more about this problem I did some more fiddling around with this issue and found something interesting.
The values that are saved are located somewhere in the registry. After finding where these values are stored I examined the content of the Guid that matches with the device description and found the issue. The changed value contains invalid data. An unmodified audio device contains a registry string and the modified audio device contains binary data. When inspecting the invalid data further you can see some of the original characters. see pictures below. I think there needs to be some conversing from a C# string to something that is appropriate for this operation.
valid:
invalid:
Thanks for the bug report @jimmyvanhest!
I definitely think there's two problems here.
The first one you've worked around by marhsalling the setting of Name to a ComThread - it should probably do this internally for any property - that should be reasonably easy to fix the PropertyDictionary.
You've found one of the gotcha's with setting properties - it does require admin privileges which is a little annoying, but theoretically it should work.
The invalid value for the string is new - I haven't seen before - looks like it's not converting the string to a known format for value.
I'll take a look into it and let you know what I find
Yeah looks like it's trying to set the raw value as a string - rather than the required "PropVariant".
Causes bad side effects for sure O_O
Thanks for looking into the issue and good to know you could reproduce it.
I have already thought about a nasty workaround I would rather not do so I'm happy you have time for this.
I was thinking about setting the registry myself with C# till a patch is out. I tested the concept by manually doing that with regedit and have seen that there are no notifications about changes like that. I have no idea if using the com interface will generate these notification but it seems a whole lot safer to do these kind of operations with the com interface anyway.
Looks like I need to change the PropVariant / Property Store code under pinning these properties.
I'm fairly sure it does raise an event for property changed - and updates itself - I'd need to check on this though.
It should be the same as changing name in control panel - and seeing that in the Audio Switcher lib
Goal.
I have been trying to change the name property of a CoreAudio device with this library.
Setup.
This could not work with the nuget package because I don't have access to the COM thread used in this library. To work around this I added this project as a subproject to mine and changed the ComThread class to public so that I could use it's invoke method to do operations I would want to do.
Observation.
When I tried changing the name property this way(running as admin else the change would not be done) the desktop environment started flashing as if it was constantly reloading. Disabling the changed audio device through Control Panel would make the flashing stop. Reenabling would make the desktop flash again. After a reboot the system would behave normally again.
I have also seen that setting the name property was not covered by any of the tests
Minimum reproducible example.
I used the following function to change the name of the default device:
I have done this for 2 devices I had available, my usb headset and my hdmi monitor.
Remarks
Is this a bug or should setting the name not even be done with this library?