nvda

0f7e961a - Use endpoint IDs instead of device friendly names to store user's preferred output device (#17547)

Use endpoint IDs instead of device friendly names to store user's preferred output device (#17547) 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`, rewrote `getPreferredDevice` to fetch the preferred device directly via `MMDeviceEnumerator.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 `deviceName` to `endpointId`. In `source/mmwave.py`, added a parameter to `_getOutputDevices` to 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`, used `nvwave._getOutputDevices` rather than `nvwave.getOutputDeviceNames` to fetch the available output devices. When saving, used the selection index of `AudioSettingsPanel.deviceList` to index into the tuple of IDs to get the value to save to config. In `source/config/configSpec.py`, moved the `outputDevice` key from `speech` to `audio`, and incremented the schema version to 14. Added an associated profile upgrade function in `profileUpgradeSteps.py`, and tests for same in `tests/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.