Volume and mute enhancements

[derekriemer]

I have a prototype addon that does the following:

1. Plays a blink sound when volume keys are pressed so you can hear how much it has changed.
2. Added a response to the mute key which shows a dialog consisting of the following:

You are about to mute the computer.
Doing this will make the computer silent, but will also make the computer useless to a blind user. An assistive technology called NVDA is running on this computer which allows the blind to get audio feedback when navigating the computer. 
Are you sure you want to mute the computer? If you are a sighted person who is using this computer, and you are muting this computer because it is currently talking, press the "Just Stop Talking" button. Otherwise, press "Mute" to mute the computer, or "Do not mute" to leave the computer unmuted.

Just stop Talking | Mute | Do not mute

I would like to make 2 actually respond to any attempt to mute the computer, but haven't gotten there yet. The motivation behind 2 is to help sighted users in computer labs who often press the mute key to get the computer to be quiet. This makes it difficult for someone using NVDA to use the computer. Exiting NVDA instead is a useful option to give them. It would also be useful to merge this ticket with a couple of other tickets that follow similar scope.

[derekriemer]

rough prototype available at https://files.derekriemer.com/volumeAndMute-1610.nvda-addon Note that the dialog needs a ton of visual help from someone who is not blind.

[jcsteh]

How do you determine when to play the sound for volume changes? Note that many volume controls don't seem to be "key presses"; i.e. they aren't detected by our keyboard hook. Both my desktop keyboard and headset volume controls aren't reported in input help, for example.

It's worth noting that Narrator reports a tool tip indicating the volume level as a percentage as you change it. The question is whether the level or the sound is more useful. If sighted users see the level, arguably, we should report it as a message rather than a sound. The flip side is that the sound is less intrusive.

I'm not so keen on having the mute thing in core. I understand the motivation behind it, but the use case seems specialised and I'm uncomfortable with trying to "override" or "intrude" when a user performs a system function. I think perhaps this one is something we should leave as an add-on. @QChristensen, thoughts?

[derekriemer]

I haven't seen volume buttons that don't work, but they exist. The only other way would be to use something like endpoint api. I simply play that file in response to the keypress.

[derekriemer]

An add-on doesn't help with this since it is user level

[jcsteh]

The odd thing is that the buttons on my desktop keyboard aren't reported in NVDA input help, but I just checked and foobar2000 detects them correctly when assigning key presses. Strange.

[Qchristensen]

Interesting, my desktop keyboard volume controls (on my desktop) look similar to others I've seen (eg on my laptop). NVDA does report them with input help, but otherwise doesn't seem to notice them, including not stopping speaking while reading if I press those keys.

The pop up that appears is a grey rectangle near the top left corner of the screen, with a blue vertical slider which is white at the top. Under the slider is the current volume (as a X for mute or 1 to 100). This automatically disappears after five seconds. While it is visible, I can interact with it with the mouse, and NVDA does read the value as I change it with the mouse only, but I still can't interact with the keyboard. Even after clicking on it, if I press say an arrow key, that will pass straight through to whatever program I was otherwise in.

Note that interacting with the system tray icon to change the icon displays a different pop up - one down the bottom right of the screen which looks quite different (albeit in the same colour scheme) and you can interact with that with the keyboard.

[derekriemer]

Does NVDA make a beep sound hwen you install the above addon? If so, it is properly detecting them. It by default doesn't do anything in response to them.

[Qchristensen]

Yes, the addon works for me - I'd say a thud more than a beep, it certainly works though, and when you press the mute button it opens a dialog asking what to do.

[derekriemer]

So it seems that some volume keys do get seen and some don't. That's interesting

[bhavyashah]

Hi, With reference to the possibility of the Mute confirmation dialog of NVDA, I would say this should be a core functionality. In labs and while working on public computers where sighted persons also co-work, installing add-ons may not necessarily be a great idea due to privacy and security concerns that sighted computer administrators may have. Muting the whole computer is the most common reaction of a sighted user to silence NVDA, and this happens frequently, disabling a visually impaired person from access to the computer. Thus, a 'Just Stop Talking' button should be a core concept which would essentially turn NVDA's Speech Mode to off. An option to configure toggle the occurrence of this dialog may also prove to be useful. Just my opinion... Thanks.

[fernando-jose-silva]

I have another suggestion. Is there a way when a blind person were to use the computer in case he called the NVDA screen reader check whether the mute windows option is active, and if you are disabled the mute option automatically. This might be a configuration to be controlled in the NVDA menu. I say this because I've been through situations of the two things were made, NVDA was off and mute was enabled in windows. A screen reader in Brazil called virtual vision possoui this feature.

[jcsteh]

Even if we had an option to show such a dialog in core, I feel it should be disabled by default. However, if we did that, it wouldn't serve its purpose in labs, etc. because people wouldn't enable the option.

My reason for wanting it disabled is that it's intrusive functionality. I might have a legitimate reason to mute my computer quickly and this dialog intrudes on that. Sure, I can disable it, but that means finding the option. We could have a "don't show this next time" option, but again, in labs, people would probably just check this the first time they see it and then others wouldn't know about it.

Regarding unmuting automatically, there's another issue about this. Briefly, my concern here is safety. We have no idea how loud the sound will actually be for a given volume level. Even 10% could be extremely loud in certain configurations; e.g. if connected to a big speaker system. If there's a potential safety risk, that suggests it should be disabled by default, but as above, it then wouldn't serve its purpose.

[derekriemer]

Hi:

You put this much more elegantly than I put it.

I think it's a good idea, the just stop talking thing actually exits NVDA in my version, so that it isn't running.

[Brian1Gaff]

Many keyboardsseem to have a mute/unmute button, but its hard to know what one might find if using somebody elses machine. Just enabling it long enough to say sound disabled sonds a little odd, but maybe that is the way to go? Brian

[Adriani90]

Regarding unmuting automatically, there's another issue about this. Briefly, my concern here is safety. We have no idea how loud the sound will actually be for a given volume level. Even 10% could be extremely loud in certain configurations; e.g. if connected to a big speaker system. If there's a potential safety risk, that suggests it should be disabled by default, but as above, it then wouldn't serve its purpose.

This could also happen if a blind person starts NVDA without knowing the current volume of the sound card. So in my view this concern is not really valid for automatically unmute the sound card. Related issue: #3049 where we discuss this in more detail.

[bhavyashah]

@feerrenrut Could you please share the current official position of NV Access on this issue? There seems to be some disagreement on whether this should be an add-on or be integrated in core, the design of the implementation in terms of turning speech mode to off or exitting NVDA entirely, similarity to #3049 , etc.

[Adriani90]

I think here is a decision needed by @michaelDCurran on how to proceed with this.

[Adriani90]

As for volume announcement, I vote for a sound indicating the volume change instead of a percentage reporting. It feels nicer from the user experience side, but I don't know if it adds more effort to the implementation.

[Adriani90]

cc: @mltony maybe you can consider this for your proposal for volume change, a sound for all applications except NVDA and a percentage reporting for NVDA volume.

[mltony]

So this appears to be orthogonal to what I am proposing. This Derek proposes here to play a sound when volume changes. Sure this could be implemented for both NVDA sound and other application sounds. If I were to work on this I would think about a broader strategy, like for example we can develop a framework of earcons that would replace NVDA messages. This blink sounds on volume up/down is one use case, another use case I can see is replacing no next character/paragraph/quickNav messages with wrong buzzer sound, etc. I have many more ideas where we can make use of sounds. But I have other more impactful ideas to work on.

[michaelDCurran]

My thoughts as requested:

• I think playing a sound / speaking percentage (configurable) when pressing volume buttons is a good idea. This may not work on all machines, but would certainly be useful on the ones it does.
• I also support the idea of a mute confirmation dialog in response to a mute button press, assuming that we check that it is going from unmuted to muted. I think the dialog should allow the user to quit NVDA, rather than silence it. NvDA users know they can press control+alt+n or windows+r and type nvda etc to get NVDA back. It would be nice if we could detect a request to mute from anywhere on the system, including System Tray, but I'm not sure that is really possible?
• I do not support any feature to automatically unmute as it is just too unsafe, see @jcsteh's reasoning.

[seanbudd]

These events may be useful for volume/mute notifications

• https://learn.microsoft.com/en-us/windows/win32/api/audiopolicy/nf-audiopolicy-iaudiosessionevents-onsimplevolumechanged
• https://learn.microsoft.com/en-us/windows/win32/api/audiopolicy/nf-audiopolicy-iaudiosessionevents-onchannelvolumechanged

These could be good for microphone mute - it's a bit more complicated for this:

• https://learn.microsoft.com/en-us/windows/win32/coreaudio/audio-endpoint-devices?source=recommendations
• https://learn.microsoft.com/en-us/windows/win32/coreaudio/device-state-xxx-constants
• https://learn.microsoft.com/en-us/windows/win32/api/mmdeviceapi/nf-mmdeviceapi-immnotificationclient-ondevicestatechanged

[josephsl]

Hi,

@LeonarddeR, I would like to propose that we revisit the decision to silence UIA notification for audio volume changes coming from Windows shell (File Explorer) if focused somewhere else as this issue justifies change of heart. This issue also justifies a thought I had about revamping UIA notification handling - rather than comparing focus objects at the UIA object level, let NVDA handle notification announcement if approved by the app module and/or the object itself, which feeds into a pull request I have worked on to bring configurable UIA notification toggle. This should take care of volume change announcements in Windows 11.

Thanks.