Skip to content
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

Open
Sypwn opened this issue Nov 27, 2023 · 2 comments
Open

Allow loading properties for NotPresent devices #71

Sypwn opened this issue Nov 27, 2023 · 2 comments

Comments

@Sypwn
Copy link

Sypwn commented Nov 27, 2023

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:

//Don't try to load properties for a device that doesn't exist
if (State == DeviceState.NotPresent)
return;

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

Sypwn added a commit to Sypwn/WinAudioAssistant that referenced this issue Dec 6, 2023
…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
@Sypwn
Copy link
Author

Sypwn commented Dec 13, 2023

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.
By allowing the app to specify which endpoint states it's concerned with, the performance impact of including properties for not present devices would be mitigated. Alternatively, we could create a CoreAudioControllerSettings struct to include both new settings.

Would appreciate your input on this, @xenolightning

@xenolightning
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants