UX fixes for WASAPI GUI and doc#15478
Conversation
See test results for failed build of commit 0245a4369f |
|
Does disabling WASAPI still make sense at all, given the bugs that are introduced when it is disabled? Maybe this should be clarified. If there is no use case for disabled WASAPI anymore, then i suggest removing this setting completely and let only the related settings to the enabled WASAPI to appear in the GUI. cc: @jcsteh |
Which bugs? Could you be more specific? WASAPI is disabled by default in 2023.2 with no critical issue to my knowledge.
There are still add-ons that do not support WASAPI. One of them is Sound Splitter maintained by @XLTechie and it is very useful for me.
|
|
There are several bugs fixed by Wasapi, see the corespomding PR. Addons should follow this technology. My understanding is that the setting whether to use Wasapi or not, was added to the gui in order to have a testing phase.Jamie can certainly correct this statement in case I am totaly wrong.Von meinem iPhone gesendetAm 20.09.2023 um 14:19 schrieb Cyrille Bougot ***@***.***>:
Does disabling WASAPI still make sense at all, given the bugs that are introduced when it is disabled?
Which bugs? Could you be more specific? WASAPI is disabled by default in 2023.2 with no critical issue to my knowledge.
If there is no use case for disabled WASAPI anymore, then i suggest removing this setting completely and let only the related settings to the enabled WASAPI to appear in the GUI.
There are still add-ons that do not support WASAPI. One of them is Sound Splitter maintained by @XLTechie and it is very useful for me.
As an alternative, there is NVDA global commands extension by @paulber19 which embeds a quite similar sound splitting feature. But:
Although being quite popular, this add-on is not (yet) in the store (Sorry Paul to insist on it!)
This add-on is NVDA's Swiss Army knife with many embedded features and a huge codebase; personally since I am always hunting bugs while running NVDA, I am a bit reluctant to install it given the number of changes that it implements in NVDA.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
There are #11169 (Infrequent crash in Firefox), #10185 (scratch at end of line) and #11061 (voice crack in text with blank lines). All these issues seem to be quite infrequent or causing only little inconveniences and impacting only few users. For many the benefit of sound splitting capability is much higher than the reported inconveniences of legacy audio system.
I fully agree that at the end, add-ons should use WASAPI. And that in the first place, they should have asked NV Access to have the needed functions/methods in the API, rather than using private methods. But they haven't.
IMO, when options are introduced by e feature flag, the following steps should be followed:
And a full release cycle should be guaranteed between each step so that non-beta users can confirm that there is no issue with each step. |
See test results for failed build of commit e1dcc4f0ab |
My experience is that WASAPI enabled is worse and has bugs to make it unusable, so removing the ability to disable it is not an option for me. I have created issue #15483 to reflect the issues I am having with WASAPI being enabled. In short it makes any audio beeps not audible unless speech is going on and bits of speech go missing. |
Follow-up of #15472.
Summary of the issue:
If NVDA is started with WASAPI disabled in config and if you enable WASAPI, the new audio options to control NVDA sounds along with voice and volume of NVDA sound are available. That's confusing because modifying them will not have any effect until NVDA is restarted.
Description of user facing changes
Enabling or disabling audio options linked to WASAPI will be done looking at current state of WASAPI usage rather than looking at the state configured for next restart.
Also added an indication in the User Guide that these options can be unavailable so that the user does not look for them when they are greyed out.
Description of development approach
Rather than checking the config, check the player currently used to determine if the WASAPI related options need to be disabled or not.
Cc @jcsteh to confirm this check.
Testing strategy:
Known issues with pull request:
None
Note
No change log needed.
Note: With the new process requiring change log to be integrated in the modifications rather than in the PR's description, we should pay attention to missing change log: has it been forgotten or is its omission intended (small fix, fix of unreleased code, etc.)
Code Review Checklist: