nvwave: make idle close delay configurable#11481
Conversation
|
This needs also documentatiom in the user guide, including a statement that chamging it can shorten the batery time. |
| # Audio settings | ||
| [audio] | ||
| audioDuckingMode = integer(default=0) | ||
| idleCloseDelay = integer(default=10000,min=0,max=86400000) |
There was a problem hiding this comment.
Wow, a day is a bit long isn't it? May be leave out the max, or set it somewhere around an hour.
| self.idleCloseDelaySpinControl = audioGroup.addLabeledControl( | ||
| label, | ||
| nvdaControls.SelectOnFocusSpinCtrl, | ||
| min=0, |
There was a problem hiding this comment.
I believe there is logic to get this from config. Search for usage of config.conf.getConfigValidation
| self._closeTimer.Start, self.IDLE_CLOSE_DELAY_MS, | ||
| wx.TIMER_ONE_SHOT | ||
| ) | ||
| if config.conf["audio"]["idleCloseDelay"]: |
There was a problem hiding this comment.
I think this can be made one if statement with the closeWhenIdle check
| ==== Caret move timeout (in MS) ====[AdvancedSettingsCaretMoveTimeout] | ||
| ==== Idle close delay (in MS) ====[AdvancedSettingsIdleCloseDelay] | ||
| Some audio drivers, notably for newer Realtek sound cards, take a long time to open the audio device causing the start or end of speech to be truncated. | ||
| By default, NVDA keeps the device open for 10,000 ms (10 seconds) after a speech utterence to improve performance on these systems. |
There was a problem hiding this comment.
SHouldn't Utterence be utterance?
| By default, NVDA keeps the device open for 10,000 ms (10 seconds) after a speech utterence to improve performance on these systems. | |
| By default, NVDA keeps the device open for 10,000 ms (10 seconds) after a speech utterance to improve performance on these systems. |
| By default, NVDA keeps the device open for 10,000 ms (10 seconds) after a speech utterence to improve performance on these systems. | ||
| However, it may be desirable to increase this timeout, to possibly further improve performance at the cost of battery power. | ||
| It might also be desirable in some cases to decrease this timeout for power savings on systems without this issue. | ||
| Setting the delay to 0 causes NVDA to close the device immediately after each utterence, matching the behaviour of version 2020.2 and earlier. |
There was a problem hiding this comment.
| Setting the delay to 0 causes NVDA to close the device immediately after each utterence, matching the behaviour of version 2020.2 and earlier. | |
| Setting the delay to 0 causes NVDA to close the device immediately after each utterance, matching the behaviour of version 2020.2 and earlier. | |
|
I understand most people with this issue now use that silencio program that
keeps it open with silence played at all times.
Jaws seems to now have something like that built in. None of the many
suggestions on here address the wake up issue and truncating, they just give
it a longer time out. Just how much power is saved by shutting down the
player?
|
|
Introducing configuration here increases the maintenance and support costs of NVDA. It's another way that end users can introduce variability into their installation. Instead we should aim to get the default value right in this case. It only seems to be an assumption that releasing the audio device will save power. I suspect what the operating system does with physical devices (for power saving) is quite separate from what NVDA does here (calling Without supporting evidence to show that this does indeed save power, or solve some other problem, I propose that this PR be closed. Typically an issue should be created so that we can have this discussion before the work is completed. |
|
I don't think we're going to be able to have a default that will suit everyone due to the nature of the problem. 10 seconds is far from optimal, because it is easy to encounter a situation where no speech is spoken for more than 10 seconds, then have the first part of speech being cut off the next time that NVDA speaks. If we want to choose a default that will definitely work, it should be set to a much longer value, especially if there are doubts about whether leaving the audio device on consumes more power. Another point to consider is that for bluetooth headphones, leaving it on does cause its battery to drain faster. |
|
The ideal solution would to get Microsoft to either fix this themselves if they can, or put their foot down regarding this behaviour and make it a hard failure when certifying audio drivers for example. Sadly I don't ever see this happening, not sure who would even be the right person to contact. This is a plague and screen reader users are far from the only users who're affected. |
|
It'd be interesting to know whether the closeWhenIdle change actually helps
those Bluetooth headsets which really aggressively power save. The
Bluetooth Audio add-on sends silence to deal with these headsets. In
contrast, the closeWhenIdle change does not send silence; it just delays
before closing the device. While that does fix one class of problem, I make
no guarantees that it fixes the Bluetooth headset problem, since I don't
have such a device to test.
|
I can confirm, this change does NOT solve the problem you describe with my BT headset. |
|
We could probably change the current implementation to play silence instead
of just keeping the device open. It shouldn't have a significant perf
impact and it would fix a broader set of problems.
|
Sounds good to me, but in that case I strongly vote to reopen this PR. |
Link to issue number:
#11024 (comment)
Summary of the issue:
In #11024, some users asked for the ability to increase the default timeout of 10 seconds for holding open the audio device. This could improve performance on systems with newer Realtek audio chipsets at the cost of some battery power. Others asked to decrease or disable the delay, as their systems do not exhibit this issue and there is concern that holding open the audio device in this way might use more power.
Description of how this pull request fixes the issue:
Adds a new advanced setting for configuring the idle close delay, and replaces the
IDLE_CLOSE_DELAYconstant innvwavewith references to this new setting.Testing performed:
Added a beep in
nvwave._closeand observed that it played according to user-configured values of theidleCloseDelaysetting.Known issues with pull request:
None.
Change log entry:
Add a second sub-point to the #11024 entry: