-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow loading properties for NotPresent devices #71
Comments
…pi.CoreAudio projects directly. Currently these have to come from the "sypwn" branch on my fork. Waiting on xenolightning/AudioSwitcher#70 and xenolightning/AudioSwitcher#71
My project that uses this is now public, if you want to take a look: https://github.com/Sypwn/WinAudioAssistant The solution to this could be shared with issue #72. Would appreciate your input on this, @xenolightning |
Interesting! I never thought about the use case of pulling properties from devices that aren't present in the system. I guess it makes sense, since the device doesn't have to be present to pull them name etc... I'm not sure about changing the constructor to optimize the loading of devices. There's some pretty gnarly performance issues with the devices in it's current state. I want to simplify the library and get away from a lot of the inherent issues, so I'm not sure #72 is the right solution there |
After migrating from NAudio.CoreAudioApi to AudioSwitcher.AudioApi, I found another regression in my application. I can no longer view properties for devices that are not connected to the system, due to these 3 lines:
AudioSwitcher/AudioSwitcher.AudioApi.CoreAudio/CoreAudioDevice.Internal.cs
Lines 94 to 96 in 27d4bf5
Removing these lines immediately allow the library to behave as desired for my project. I doubt you'd accept that as a PR though. It should be some kind of setting that's stored in the CoreAudioController when it's created. I don't see a pattern in the library for how you would implement something like that. An optional parameter in the CoreAudioController constructor? Containing just that flag? Or wrapped in a new CoreAudioControllerSettings struct? Let me know what you think, and I'll work on the implementation.
Thanks
The text was updated successfully, but these errors were encountered: