-
-
Notifications
You must be signed in to change notification settings - Fork 651
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
Remove winmm support from NVDA #17496
Conversation
…ing WinMM from nvwave.initialize
# Conflicts: # user_docs/en/changes.md
@coderabbitai please open an issue related to this one, for switching to using endpoint IDs rather than friendly names for identifying the selected output device in user configuration. |
Tip For best results, initiate chat on the files or code changes. @SaschaCowley: I've opened a new GitHub issue as requested: #17497 🔗 Analysis chain🏁 Scripts executedThe following scripts were executed for the analysis: Script:
Length of output: 499 ✏️ Learnings added
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR seems incomplete:
- Various audio features (e.g. sound split, mute other apps, etc.) only work if WASAPI is enabled:
- in settings dialog, the check of WASAPI to enable or disable controls for such settings should be removed (see (
nvwave.usingWasapiWavePlayer
calls) - in the User Guide, the documentation of these settings mention WASAPI requirement; this should be removed
- in settings dialog, the check of WASAPI to enable or disable controls for such settings should be removed (see (
- In config spec,
WASAPI
should be removed fromaudio
section, and this removal should be documented in API-breaking changes. Or in case you want to keep it as a no-effect parameter, you should at least document it in the change log and remove all of its usage in NVDA's code. - I also wonder if the removal of
AdvancedPanelControls.wasapiComboBox
should be documented in the API-breaking changes.
@CyrilleB79 thanks for the thorough notes. I believe I've addressed all of your points now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @SaschaCowley - mostly looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @SaschaCowley
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reads well, good work.
Thanks Sascha this is very appreciated cleanup. |
@SaschaCowley, after this PR, if I plug an USB headset, but select my PC speaker for NVDA audio output, the sound still comes in the headset rather than from PC sdpeakers. |
@SaschaCowley it seems the NVWave advanced logging channel is still there, I mean the one introduced in #11582 and #11614. Does it have to be removed as well? Or is it not related? |
Closes #17512 Fix-up of #17496 Summary of the issue: After the removal of winmm support, SAPI5 synthesisers failed to initialise. This is because we switched from integer-based IDs as used by winmm, to ID strings as used by Windows Core Audio. Description of user facing changes SAPI5 synthesisers now initialise correctly. Description of development approach Rather than calling `outputDeviceNameToID` to index into the audio outputs returned by SAPI, iterate over them and look for one whose `Description` matches the friendly name of the output device to use as stored in the user's config. Testing strategy: Tested loading SAPI5 with a number of output devices selected, and changing output devices with SAPI5 loaded. Known issues with pull request: None.
Link to issue number:
Closes #16080
Closes #2067
Summary of the issue:
The support for WASAPI (and Windows' Core Audio APIs more broadly) in NVDA is now quite mature, and maintenance of our winmm support is becoming untenable.
Description of user facing changes:
The option to use WASAPI for audio output has been removed from NVDA's advanced settings. This has been on by default for some time, so it is unlikely to affect most users.
As the Mmdevice API does not have the concept of an ID to refer to the default output device, "Microsoft Sound Mapper" is no longer an option in the output device selection in Audio Settings. Users can instead choose "Default output device".
Description of development approach
Removed all references to winmm in
nvwave.py
. Rewrote the device enumeration to use the Mmdevice API, via pycaw. Slightly modified the device selection logic in the settings GUI in light of Mmdevice not having an equivalent to Microsoft Sound Mapper.Testing strategy:
System and unit tests, as well as running NVDA, and changing output devices, including plugging and unplugging headphones while NVDA was running.
Known issues with pull request:
None
Code Review Checklist:
@coderabbitai summary