Use endpoint IDs instead of device friendly names to store user's preferred output device#17547
Conversation
…f["audio"]["outputDevice"]
See test results for failed build of commit 6c9a566a08 |
# Conflicts: # user_docs/en/changes.md
|
What will be the recommended way to get the WinMM device index of the preferred output device, if a third-party synthesizer plugin cannot be migrated to WASAPI? |
See this Microsoft code sample on how to get the waveform ID from an Endpoint ID string. |
|
There are still some plugins which use Will there be a new helper function to convert endpoint IDs to WinMM device indexes? Or will they be encouraged to do conversion themselves instead of relying on helper functions in nvwave? Seems that in NVDA, the SAPI4-related code is the only place where |
|
@gexgd0419 the plan is to remove |
seanbudd
left a comment
There was a problem hiding this comment.
Nice, only a couple lint fixes
Co-authored-by: Sean Budd <sean@nvaccess.org>
|
@SaschaCowley - has this been announced on the API mailing list? |
|
Hi, it appears there is a regression that causes user settings to become corrupt (to be filed as a separate issue once the relevant log fragment is obtained). Thanks.
|
Fixes #17587 Fixes #17588 Summary of the issue: The profile upgrade steps introduced in #17547 would cause NVDA to crash, and the user's configuration to be reset, if the user had an audio output device set in their NVDA configuration. Description of user facing changes Upgrading from configuration version 13 to 14 no longer crashes NVDA and resets the user's configuration. Description of development approach The issue was caused because `config.profileUpgradeSteps.upgradeConfigFrom_13_to_14` attempts to import `nvwave`, which, through its own imports, eventually attempts to use gettext. Since gettext has not yet been initialised, this raises an exception. As we are so early in NVDA initialisation, this exception causes the rest of NVDA's initialisation to fail critically. To resolve this, `_getOutputDevices` and `_AudioOutputDevice` have been moved to the new `utils.mmdevice`. I initially thought to move them to `audio.utils`, but initialisation of `audio` runs into the same problem. Testing strategy: Checked out `a7fa0d6`, made sure the config version was `13`, ran NVDA and selected an audio output device. Checked out `fixProfileUpgrade`, ran NVDA, and ensured that it ran as expected, the profile was correctly updated, there was no loss of settings, and the correct output device was in use.
Link to issue number:
Closes #17497
Summary of the issue:
NVDA currently stores the friendly name of the user's preferred audio output device.
Description of user facing changes
None.
Description of development approach
In
nvdaHelper/local/wasapi.cpp, rewrotegetPreferredDeviceto fetch the preferred device directly viaMMDeviceEnumerator.GetDevice.Added manual checks that the fetched device is a render device, and that its status is active, since these conditions were guaranteed to be met since the previous code only iterated over devices which met those prerequisites.
Renamed
deviceNametoendpointId.In
source/mmwave.py, added a parameter to_getOutputDevicesto return a value representing the system default output device.Also made the type hints more self-documenting by using a
NamedTuple.In
source/gui/settingsDialogs.py, usednvwave._getOutputDevicesrather thannvwave.getOutputDeviceNamesto fetch the available output devices.When saving, used the selection index of
AudioSettingsPanel.deviceListto index into the tuple of IDs to get the value to save to config.In
source/config/configSpec.py, moved theoutputDevicekey fromspeechtoaudio, and incremented the schema version to 14. Added an associated profile upgrade function inprofileUpgradeSteps.py, and tests for same intests/unit/test_config.py. Updated all occurrences of this config key that I am aware of to point to the new location.In
source/synthDrivers/sapi5.py, rewrote the device selection logic again to work with endpoint IDs.Testing strategy:
Built from source and ensured that changing output devices works as expected.
Ensured that saving the config worked, and that the output device was selected correctly when restarting NVDA.
Tested activating SAPI5 with different output devices selected.
Known issues with pull request:
SAPI4 still doesn't work (#17516 ), this will be fixed in a future PR.
Endpoint ID strings are not human-readable.
Code Review Checklist:
@coderabbitai summary