forcing unmute and volume of sound card

[nvaccessAuto]

Reported by joshknnd1982 on 2013-03-05 13:01 In the next version of NVDA, please make it so that when NVDA starts up it will check to see if your sound cards are not muted. If they are it will force them to not be muted anymore. And it would also check to make sure your speaker volume is not set to 0. If it is set to 0, NVDA will automatically raise the volume to 30 or 40% to make sure sound can be heard. Sometimes when you plug NVDA into a computer and try to use it or if you attempt to install it I find the last person using the computer has muted the sound or turned the volume all the way down or both. If NVDA does these muted speaker and volume checks and unmutes the sound card and raises the volume if needed then sighted help will not be necessary just to unmute speakers and raise sound card volume so NVDA can be used. Sound card volume is different than the volume found under preferences under voices and this is what NVDA would have to check for and correct if needed. If the volume is not set to 0 and is no more than 10% then NVDA will not perform the unmute or raising of the volume. I think this is a very important feature for a screen reader to have so blind people don't have to ask for help if speakers are muted. not everyone has a braille display so this is a good way to make for absolute certain there is sound at NVDA startup. this should apply to all operating systems, Since unmuting and changeing volume are different in each OS it will be necessary probably for NVDA to detect what OS it is running on and then unmute speakers and change volume accordingly. Blocking #4926

[nvaccessAuto]

Comment 1 by briang1 on 2013-03-05 14:38 I agree this would be handy. but I fear that as every computer will have a different sound card set up, I don't know how it could be done. as you suggest its different to the main system volume and therefore even if you did put some test of this in and a look up on how to do it then nexst week a new card totally different would appear making it fail.

I have a prgram for xp which allows the sound info to be saved and reloaded, but it most certainly will not work if the file is moved to another computer with a different sound hardware. Besides, it would also have to put back what was there afterwards of cours...

[nvaccessAuto]

Comment 2 by joshknnd1982 (in reply to comment description) on 2013-03-05 16:45 Window-eyes does it somehow, though in the latest version. it can check to see if your sound is muted, unmute it, and raise the volume if needed. Replying to joshknnd1982:

In the next version of NVDA, please make it so that when NVDA starts up it will check to see if your sound cards are not muted. If they are it will force them to not be muted anymore. And it would also check to make sure your speaker volume is not set to 0. If it is set to 0, NVDA will automatically raise the volume to 30 or 40% to make sure sound can be heard. Sometimes when you plug NVDA into a computer and try to use it or if you attempt to install it I find the last person using the computer has muted the sound or turned the volume all the way down or both. If NVDA does these muted speaker and volume checks and unmutes the sound card and raises the volume if needed then sighted help will not be necessary just to unmute speakers and raise sound card volume so NVDA can be used. Sound card volume is different than the volume found under preferences under voices and this is what NVDA would have to check for and correct if needed. If the volume is not set to 0 and is no more than 10% then NVDA will not perform the unmute or raising of the volume. I think this is a very important feature for a screen reader to have so blind people don't have to ask for help if speakers are muted. not everyone has a braille display so this is a good way to make for absolute certain there is sound at NVDA startup. this should apply to all operating systems, Since unmuting and changeing volume are different in each OS it will be necessary probably for NVDA to detect what OS it is running on and then unmute speakers and change volume accordingly.

[bhavyashah]

I wholeheartedly agree with this feature request. It can be incredibly annoying when a sighted person mutes a computer I am going to use shortly and I am left wondering whether NVDA is off, or the computer hasn't booted up, or what not. Since agreeing on the ideal percentage to which NVDA should raise the volume to if system volume is at 0% may be tricky and may vary from system to system, it would be perfect if a control to set that was also provided to the user. While UX and implementation cost may be non-trivial, I would recommend against marking this ticket as a P4 and instead working on this in subsequent projects. Thoughts?

[Brian1Gaff]

I can only agree, other than that, there ought to be some way in 7 and up to tell if mute has been applied even if its only by just unmuting. I suspect though tht this might need a specific windows utility to do this. I have a keyboard with a key for mute unmute and although it can be annoying if you hit this yourself, at least you know how to reverse it!

Mouse users seldom bother to turn off the screenreader they mute the audio. Then forget they have done it. Brian

bglists@blueyonder.co.uk Sent via blueyonder. Please address personal email to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field.

[LeonarddeR]

@DerekRiemer: might be something you could work on, given the efforts you've put into hooking battery charger connection/disconnection, etc.

[derekriemer]

This requires the endpoint api. @michaelDCurran do you recommend touching this in c++ in some dll, or do you have an idea of how I can do this in python? I've tried, and am not sure how it can be done in Python.

[michaelDCurran]

Do you mean you need to use the same stuff we use for detecting existing audio when deciding for audio ducking?

If so, I'd just create more functions in nvdaHelper/local/mixer.cpp

Its not impossible to do in Python, but you'd have to code all those COM interfaces by hand. It is simply not worth the time when the headers are available in c++

[derekriemer]

Oh, wo, we already have that c++ file, sweet! Mind if I assign this to me?

[michaelDCurran]

Fine with me.

[Adriani90]

@derekriemer any updates on this? @Robert-J-H you have created an add-on for this. maybe raising a Pull Request would bring this to NVDA's core.

[jscholes]

Discussion has been taking place on the referenced pull request page (https://github.com/nvaccess/nvda/pull/7506), where both @derekriemer and @leonardder stated they currently lack the time to work on this as a couple of weeks ago. It would be best to keep discussion in a single place now that a possible implementation has been created.

[feerrenrut]

Some thoughts about implementation of this from: https://github.com/nvaccess/nvda/pull/7506#issuecomment-607074699

We are still uncomfortable with situations where this may causes damage (to equipment or people) if the system is unmuted when connected to a loud system or headphones.

A smaller step which will still solve the problem for power users would be an assigned by default shortcut that unmutes and sets volume very low (eg 1%), and increases the volume on subsequent presses. While this won't fix the issue for novices, this should at least solve the problem for people who are trying to get their work done and find that their computer has been muted.

There is also a remaining issue on this PR. The device that is unmuted is the default device, NVDA may be configured to use a different device.

[Robert-J-H]

This concern doesn't make sense to me. A sighted user has the same problem after all; he can't say how high the volume is until he unmutes the audio. Windows has no VU meter, at least not one that measures the sound after the speaker. Our addon solved the problem quite nicely, I should think.

[Brian1Gaff]

Yes, perhaps a warning of sime kind a noise that won't break the speaker if its too loud?

[jscholes]

@Robert-J-H

This concern doesn't make sense to me. A sighted user has the same problem after all; he can't say how high the volume is until he unmutes the audio.

I don't follow. Surely they can see the slider's position? Obviously Windows cannot determine how loud the actual audio production will ultimately be, because even 1% can be deafening if you have external amplification set to unreasonable levels. But the concern here is valid and targeting the majority of cases rather than the edge ones. For most users, there is a certain Windows volume level at which noise starts to become uncomfortable, and sudden exposure to that should be avoided.

[Robert-J-H]

Let's be clear, it is very, very unlikely that you can damage the speakers through TTS. To burn the tweeters, the sound had to be high energy in the treble spectrum. You don't have that with 22050 Hertz or less speaker rate. If the speakers break down, they were of inferior quality to begin with. Same is true for hearing damage, it will only manifest itself if you are exposed to a loud volume over longer times. I don't know any desktop computer speakers that could a damage in less than an hour, especially not those in computer labs. Headphones are a bit different but you would simply take them off if it gets to "hot" and even those wouldn't be able to produce permanent damage over short term usage. I mean, I've played electric guitar in Rock concerts over ten years long. I've not suffered from any degradation although our PA (for monitoring) had about 3000 Watt. It would be possible to increase the volume continuously from a muted state up to the current volume or to stop it if any key is pressed (while a message is repeated that says to do so). But I do personally think that it is fairly inconvenient in comparison to a simpler volume recall. The only advantage that I can see is for those public places where everyone thinks he must play around with the speaker knob. But again, the hearing damage is no valid argument here, only how much you might startle others. And the displayed volume in the taskbar expresses nothing, even for sighted users. This feature is in my opinion long enough dragged out for rather flimsy reasons since simply starting the screen reader normally might have the same issues.

[jscholes]

@Robert-J-H I don't necessarily think the proposed 1% solution is the best pattern, but nor can our argument boil down to: "you won't break a person's ears or speakers, so do what you want".

[Robert-J-H]

Has anyone ever encountered such a case where either speakers or ears were negatively affected? Do we now base our criticism on internet myths? I wouldn't say anything if a normal NVDA start on a shared computer couldn't hold the same dangers. I don't like loud levels either. That's why the addon had a minimum and maximum volume and the previous (before muting) volume could only be restored within those bounds. There are some methods to pick up the volume before a sound reaches the speakers. Unfortunately, those require mostly administrator rights. It is also possible to enable and monitor the mic input during startup (when the NVDA signet is played). This is especially useful for deaf-blind people when they log on to a computer with speakers and they don't want to disturb other people. I might try an experimental build with a longer startup sound that gradually increases in volume until any key is pressed - only when a muted state was encountered.

On 01/04/2020, James Scholes notifications@github.com wrote:

@Robert-J-H I respect your opinion, and disagree with it equally respectfully. I don't necessarily think the proposed 1% solution is the best pattern, but nor can our argument boil down to: "you won't break a person's ears or speakers, so do what you want".

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/3049#issuecomment-607460377

[jscholes]

Just to be clear, I don't disagree with your data. I don't have enough audio knowledge to verify that it is correct, but my concerns aren't related to equipment damage or health effects so it doesn't really matter. My concerns are usability-related, because there are many many cases in which a computer bursting out into speech and sound at an uncomfortably loud volume is completely inappropriate. Libraries, examinations or a room with a sleeping baby, just to name a few.

Likewise, I don't have any experience with your add-on, because I don't currently use shared computers at all. If your solution to this problem has solved these concerns, that's fantastic, and I hope those solutions make it into NVDA core in some way. I'm simply serving to raise these usability concerns so that they are logged and entered for discussion.

[Adriani90]

This argument doesn‘t make sense to me to be honnest. A sighted person could change the volume on the system and later on, a blind person can just start Nvda normally and can terrify the poor baby without knowing that the system volume has been changed. This argument is just noise in my view and Is not really related to mute or unmute the sound card. Otherwise, if this concern would have realized, until now alot of users would report that their equipment has been damaged by Nvda also without this feature. But I never heared such an user report.

Von meinem iPhone gesendet

Am 02.04.2020 um 02:10 schrieb James Scholes notifications@github.com:

 Just to be clear, I don't disagree with your data. I don't have enough audio knowledge to verify that it is correct, but my concerns aren't related to equipment damage or health effects so it doesn't really matter. My concerns are usability-related, because there are many many cases in which a computer bursting out into speech and sound at an uncomfortably loud volume is completely inappropriate. Libraries, examinations or a room with a sleeping baby, just to name a few.

Likewise, I don't have any experience with your add-on, because I don't currently use shared computers at all. If your solution to this problem has solved these concerns, that's fantastic, and I hope those solutions make it into NVDA core in some way. I'm simply serving to raise these usability concerns so that they are logged and entered for discussion.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jscholes]

I don't think I'd describe it as an argument. The question is whether NVDA wants to target maximum usability when implementing a useful feature. And the fact is, many users will effectively mute the system by moving the volume slider all the way down to 0, so some sort of startup volume preference makes sense from that perspective as well.

If this feature is implemented without any of this being take into account, that's fine. I don't have a horse in the race, but I do think usability is important. Which is why the question about alternate vs default audio devices is also critical. This cannot just be implemented as a few lines of code which unmutes the default audio device at NVDA startup and calls it a day.

[Adriani90]

But startup volume prefference would have made sense since the first day of Nvda‘s development. Why should we add this argument now, 14 years later? I don‘t really understand. And I can certainly agree with the second point regarding the output device. But I think this can be solved in the same pull request during the review process. It is not impossible.

Von meinem iPhone gesendet

Am 02.04.2020 um 05:30 schrieb James Scholes notifications@github.com:

 I don't think I'd describe it as an argument. The question is whether NVDA wants to target maximum usability when implementing a useful feature. And the fact is, many users will effectively mute the system by moving the volume slider all the way down to 0, so some sort of startup volume preference makes sense from that perspective as well.

If this feature is implemented without any of this being take into account, that's fine. I don't have a horse in the race, but I do think usability is important. Which is why the question about alternate vs default audio devices is also critical. This cannot just be implemented as a few lines of code which unmutes the default audio device at NVDA startup and calls it a day.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jscholes]

But startup volume prefference would have made sense since the first day of Nvda‘s development. Why should we add this argument now, 14 years later?

I'm afraid I don't understand the question. The same could be said for the majority of features of NVDA which have been added since then.

[Adriani90]

Yes, but we don‘t usually argue against a new feature by saying this would introduce a concern which exists anyway already since years. I would rather support such a feature and would try to discuss how to tackle the startup volume problem during a review process in the pull request.

Von meinem iPhone gesendet

Am 02.04.2020 um 06:14 schrieb James Scholes notifications@github.com:

 But startup volume prefference would have made sense since the first day of Nvda‘s development. Why should we add this argument now, 14 years later?

I'm afraid I don't understand the question. The same could be said for the majority of features of NVDA which have been added since then.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[feerrenrut]

One of the major concerns is about unmuting automatically rather than due to user action. When an automatic action is taken that is against the wishes of the user, the outcome will be worst for a novice user. They are by definition the least likely to know what to do.

Perhaps physical damage is unlikely, but causing disruption by automatically changing settings makes NVDA look bad, whereas a computer being muted by a 3rd party leaves the blame on them, especially if there is a mechanism within NVDA to address it.

When using Windows visually there are lots of ways to mitigate the concerns around volume levels. The volume set can be seen and adjusted before unmuting. A sighted user who is unsure can easily set the volume to 0 and increase it slowly.

Finally we must consider deaf-blind users who may intentionally have the volume off.

[Robert-J-H]

@feerrenrut

One of the major concerns is about unmuting automatically rather than due to user action. When an automatic action is taken that is against the wishes of the user, the outcome will be worst for a novice user. They are by definition the least likely to know what to do.

Perhaps physical damage is unlikely, but causing disruption by automatically changing settings makes NVDA look bad, whereas a computer being muted by a 3rd party leaves the blame on them, especially if there is a mechanism within NVDA to address it.

I don't follow, automatic changes without user interaction happen all the time. That's what settings, profiles and the installation wizard are for. Our highest responsibility is to ensure that NVDA starts such that the user can work with it immediately. Again, if you start NVDA and the last user did set all volume to the maximum (system, active speaker), then the effect is the same - confusion and disruption. Imagine a user logging on to a computer and mute is on, he might fiddle with the speaker volume, plug and unplug the headphones, hunt for the mute key on a keyboard that has none etc. and finally he has to fetch sighted assistance. If it is in a class, valuable minutes go by for naught. We can at least give some relief in that on the software side a minimum volume is guaranteed. When using Windows visually there are lots of ways to mitigate the concerns around volume levels. The volume set can be seen and adjusted before unmuting. A sighted user who is unsure can easily set the volume to 0 and increase it slowly. There's no guarantee that the volume is displayed in the taskbar and I doubt that a lot of people would go to those lengths (asking for forgiveness, rather than permission comes to mind)

Finally we must consider deaf-blind users who may intentionally have the volume off.

That's all saved in their personal profile, is it not? You can have either speech turned off, have the synth set to no speech or "none" chosen as output device. The blame goes therefore to the system administrator and instructors that did set up the accounts with NVDA and that is how it should be IMHO.

[lukaszgo1]

The trouble here is that the beginners are most likely to suffer from the computer being muted so the argument given by @feerrenrut is in my opinion invalid. It is also important to stop looking at this like @feerrenrut did saying:

One of the major concerns is about unmuting automatically rather than due to user action. When an automatic action is taken that is against the wishes of the user, the outcome will be worst for a novice user. They are by definition the least likely to know what to do. Perhaps physical damage is unlikely, but causing disruption by automatically changing settings makes NVDA look bad, whereas a computer being muted by a 3rd party leaves the blame on them, especially if there is a mechanism within NVDA to address it

Its completely irrelevant who is to blame for the machine being muted what we should discuss here is how to solve it. From the above discussion I believe the implementation should ensure the following criteria are met:

• The unmuted device is the one which is configured as a device through which NVDA speaks at the moment.
• It has to be possible to disable automatic unmuting mostly for deaf-blind users.
• It should be possible to specify a volume to which the unmuted device is being raised.

In my opinion the variant in which the unmuting is not being done automatically during startup but has to be initiated by the user is very unfriendly - for example my current laptop if not being overloaded is able to work completely silent. I have enough light perception to determine if it is on but for completely blind user it is not possible so there is no way to determine if the pc in question has not booted or if it is just silenced.

@feerrenrut Would you agree with the summary above? I believe before someone tries to implement this we need to clearly define what is required in the initial implementation.

[Adriani90]

One of the major concerns is about unmuting automatically rather than due to user action. When an automatic action is taken that is against the wishes of the user, the outcome will be worst for a novice user. They are by definition the least likely to know what to do.

Exactly the novice users would benefit from this feature. Regarding automatic actions, note that NVDA already changes settings in Windows, i.e. overwriting the functionality of the capslock key to figure as NVDA key. A novice user might wonder why the capslock key is not working.

But back to the subject, I think this concern can easily be addressed by an appropriate implementation. My proposal is as follows:

1. In the synth settings of NVDA, add a check box "unmute the currently selected output device when NVDA starts" 1.1 If this checkbox is enabled, an edit box containing the value of the current volume of the selected output device appears which let's you specify the volume that you want to have when NVDA unmutes the sound card. Label could be "set output device volume automatically at ..." 1.2 The automatic volume setting would apply only in case NVDA unmutes the sound card, and not everytime when NVDA starts
2. The checkbox in 1. and the edit field in 1.1 should also appear in the welcome dialog after installing NVDA.

This implementation would make this feature transparent for everyone who is using NVDA, even for novice users who are installing it for the first time. I don't see any disadvantages from this implementation. This feature could be documented properly also in the user guide to avoid any misunderstandings.

[Adriani90]

And for further discussions on related matters, see also issue #6427.

[feerrenrut]

This is an issue that NV Access has talked about many times, and spent a lot of time considering the variations in use cases. It's an old issue, that seems to have made very little progress. Rather than dreaming big, and hoping for the full bells and whistles implementation, we are suggesting a much smaller implementation that doesn't try to solve all of the UX issues. By initially solving the core problem for some users without any risk of negatively affecting other users we can make progress. Once implemented this would be easy to leverage for addons, if further functionality is desired. We are trying to be clear about what we will accept as a first PR to get the ball rolling. Lets discuss subsequent automatic aspects later.

I don't agree with many of the arguments presented, but I don't think it is worth further discussion at this point. If someone is interested in the full bells and whistles implementation after the basic functionality is implemented, we would consider a PR if they can clearly show they have considered the UX edge cases and addressed them.

[Robert-J-H]

Reef, the point is that we can't even agree on the basic case and the edge cases are somewhat illusive, there's still no evidence of their existence or what NVAccess defines as such. We had a perfectly working addon with some 80 posts with feedback. The major problem and the reason it isn't published is that it can't work in environments where it would count. That is, on shared computers where a lot of functionality (no addons or only those installed by administrators) is restricted, not to mention secure or locked screens. In essence, there was never a complaint about automatic unmuting but rather that it was applied to late in the startup phase or that it didn't work due to the above limitations.

On 06/04/2020, Reef Turner notifications@github.com wrote:

This is an issue that NV Access has talked about many times, and spent a lot of time considering the variations in use cases. It's an old issue, that seems to have made very little progress. Rather than dreaming big, and hoping for the full bells and whistles implementation, we are suggesting a much smaller implementation that doesn't try to solve all of the UX issues. By initially solving the core problem for some users without any risk of negatively affecting other users we can make progress. Once implemented this would be easy to leverage for addons, if further functionality is desired. We are trying to be clear about what we will accept as a first PR to get the ball rolling. Lets discuss subsequent automatic aspects later.

I don't agree with many of the arguments presented, but I don't think it is worth further discussion at this point. If someone is interested in the full bells and whistles implementation after the basic functionality is implemented, we would consider a PR if they can clearly show they have considered the UX edge cases and addressed them.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/3049#issuecomment-609678672

[feerrenrut]

As described in a previous comment , this is what we will accept as a first step:

A smaller step which will still solve the problem for power users would be an assigned by default shortcut that unmutes and sets volume very low (eg 1%), and increases the volume on subsequent presses. While this won't fix the issue for novices, this should at least solve the problem for people who are trying to get their work done and find that their computer has been muted.

This handles what we see as the basic use case:

As a non-novice user, one who is familiar with more obscure NVDA shortcuts. When finding that NVDA is not speaking when interacting with my computer, I can attempt to unmute and set the volume to a level I can hear. This allows me to continue working, or rule out volume / mute as the reason I can not hear NVDA.

To address some other coments:

• Knowing whether your computer is on is a separate concern.
• The NVDA hotkey can be used ensure NVDA is running.
• @Adriani90 citing other ways that NVDA can be disruptive is not a reason to create new ways to be disruptive.

Other use cases to consider when building on this basic functionality:

• As a deaf-blind user, I wish to leave my entire system muted so that no applications make sounds that I might not be aware of. This is so that I don't worry about disrupting others, and so that I can use my computer privately.
• As a professional using my computer at work and home. At home other users mute my computer before using it so they aren't disruptive. I want to be able to unmute my computer independently at work. At home I don't want others to be surprised by it unmuting automatically.

[Adriani90]

@feerrenrut I have the feeling that my comment has not been read completely. When we discuss a new feature, this should be treated fairly and according to equal criteria which have been applied for features already in place. We cannot bring arguments against one new feature which have been simply ignored for other features in the past.

And regarding other concerns, I really don't understand the point here. If the implementation makes this feature transparent to everyone and you as an user can choose if this should be done automatically or not, where is the problem? If you don't want to accept this feature at all which is my feeling at the moment, then please just comment directly that you don't want to have it in NVDA and close this. But then be also aware of the feedback of the community, this discussion will certainly be circulated through many mailing lists etc.

My feeling is that you guys at NV Access argument from a more developer perspective but you did not really consulted the users on this matter. Please don't take me wrong, I don't want to blame anyone here. But in my opinion we should keep discussing new features in a fair way, also considering user feedback on this.

Do you have at NV Access any evidence from users being totally agains this feature because of the concerns metioned? Please consult also the discussions on the NVDA-Addons list with regard to this feature and see what users actually expect. This would be very useful to continue this discussion.

[feerrenrut]

We cannot bring arguments against one new feature which have been simply ignored for other features in the past.

I'm not really sure what you mean by this, there is no predefined list of things that are considered. We do our best to consider what seems relevant on a case by case bases. Since this issue was created, there have been concerns about potential adverse effects.

as an user can choose if this should be done automatically or not

Then the user who turns off the automatic feature has no solution at all.

We would prefer not to close this issue. We have made a suggestion that avoids an "all or nothing" mentality, one that can be built upon. We are confident that this will provide a solution to the core issue for most users, for what is generally a rare problem. Again, this can be built upon to provide solutions for other edge cases. This solution does not have any risk of adverse effects. We are trying to consider the use cases of more than just the people who are vocal on Github.

An automatic solution is more work, will take longer to implement, requires answering a number of extra UX questions, and is essentially just an extension of a manual shortcut based solution. I'm arguing we should start with the simpler solution. At least then there will be some solution rather than none.

[bhavyashah]

A few thoughts below:

• In regards to the basic implementation being expected, I have a question. Would this keystroke have any effect if the computer is not muted, but the volume is too low for NVDA to be actually audible?
• Also, though I am not a user of the Shared Computer add-on, I do use the Tony's Enhancements add-on, which contains a feature relevant to our discussion. Below is an excerpt from its documentation: "NVDA volume • NVDA+Control+PageUp/PageDown - adjust NVDA volume. This option controls the volume of NVDA speech as well as all the other sounds and beeps produced by NVDA. The advantage of this option compared to adjusting volume of a speech synthesizer, is that it affects the volume of all the beeps proportionally." To clarify, NVDA+Ctrl+Page Up/Page Down do not mute or unmute, but only affect the volume slider. Perhaps some of the code of this add-on could be borrowed for the basic implementation.
• Also, I don't think hearing loss or damage to playback equipment are the concerns being raised. The concern is, as I understand it, that unexpectedly loud audio can be hurtful to one's ear, disrespectful to those in one's proximity, and embarrassing in a public setting. Having said that, the status quo, as others have pointed out, is one where you start NVDA not knowing how loud NVDA may be. Therefore, this concern cannot be, and was not, used as an argument against implementing a force unmute feature. The concern with force unmute is the very concern that already plagues us far more frequently.
• Having said that, I think @jscholes brings up excellent points. I think having an option to configure a startup volume for NVDA would be quite useful. One could argue that this can already be done by adjusting NVDA's speech volume in Voice Settings and then saving configuration, but the simple response to that is that that excludes NVDA's beeps and tones. However, the bigger point I would make is that a force unmute feature and a startup volume option should be thought of as two independent issues. Yes, startup volume would address some concerns with force unmute, but those concerns are not unique to force unmute in the first place.
• Simply put, both force unmute without startup volume or startup volume without force unmute would be incredibly valuable to have. I do not see much of a clash or dependence between the two.
• Lastly, I think the suggested basic implementation is a decent starting point as it does serve the use cases and accounts for potential issues. I don't think it is the best solution, but it would certainly do the job whilst limiting the implementation cost.

[XLTechie]

@bhavyashah, What Tony's add-on is probably doing, is changing the volume of NVDA in the system volume mixer. Of course, the NVDA sounds being far louder than NVDA speech, is a long standing and ridiculous bug, but that is a different issue.

I don't use that add-on, but I do use the system volume mixer, and have found that volume setting to be consistent across restarts of the machine. Portable copies of NVDA at 100% volume, are much louder than my installed copy at 100%, because of the system volume mixer settings I have configured.

Which, in fact, is an argument in favor of @Adriani90 and @Robert-J-H's positions. A novice user may not even be aware that the system volume/muting is different from the independent, internal, NVDA volume. Such a user won't know to enable the unassigned shortcut as @feerrenrut desires, and won't know that they even need such a thing. That's why something automatic seems preferable in this case, although defeatable in config, and probably still with the unassigned manual shortcut for experts.

Is it definitely true that other screen readers do this? I have heard that Window-eyes does: does Narrator?

[Robert-J-H]

I think the sound volume should be in the Synthesizer settings ring, perhaps in relation to the speech volume. With regard to embarrassingly loud volume: This happens to me only when updating NVDA which seems to ignore all profiles and uses just 100 %.

On 23/06/2020, Luke Davis notifications@github.com wrote:

As an aside: could someone (@Adriani90?) please correct the spelling of "forcing" in the title of this issue? Feel free to delete this comment if so.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/3049#issuecomment-648374257

[codeofdusk]

Given the recent acceptance of #16273 and #16286, I think a case could be made for taking this as well if no Braille display is configured/detected.

CC @mltony, @seanbudd

[michaelDCurran]

As been said many times by @jcsteh and myself, there are dangers to automatically unmuting or changing the volume of a sound card. there are situations where even say 10% could be damaging to equipment or your hearing. A key command to unmute (which was always guaranteed to work, and which could be pressed again to mute) would be fine. Or if we absolutely must, then an NVDA setting (which is off by default) that when turned on would automatically unmute on start-up. But turning on the setting should warn the user about the dangers. I would never accept a feature in NVDA that automatically unmuted by default.

[seanbudd]

I think an option to automatically set the system volume when NVDA starts is the best path forward.

The option would be in 2 parts. A dropdown "Set system volume when NVDA starts":

• disabled (default): do nothing
• unmute: just unmute when NVDA starts, keep preset volume (which may be low or 0)
• custom volume: unmute and set a volume, enables a spin control for 0-100

[Adriani90]

Important to consider for who ever implements this: the state of the sound card before starting NVDA should be returned after closing the NVDA process.

[LeonarddeR]

please also take the status of the windows audio service (Audiosrv) into account. I believe that narrator starts this when it is not active.

[jscholes]

@Adriani90

the state of the sound card before starting NVDA should be returned after closing the NVDA process.

I personally don't think this should be in scope. If the user has changed their audio settings while NVDA is running, returning them to some other state based on how they were set before NVDA started seems quite arbitrary, and could easily fail if NVDA doesn't gracefully shut down.

[Adriani90]

Still, if it fails then it is an exception. But if settings which affect the whole Windows system have been changed while running NVDA, then this will result in huge confusions when blind and sighted people work on the same machine. So we should definitely preserve such settings only when NVDA is running.Von meinem iPhone gesendetAm 12.03.2024 um 15:40 schrieb James Scholes @.***>: @Adriani90

the state of the sound card before starting NVDA should be returned after closing the NVDA process.

I personally don't think this should be in scope. If the user has changed their audio settings while NVDA is running, returning them to some other state based on how they were set before NVDA started seems quite arbitrary, and could easily fail if NVDA doesn't gracefully shut down.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[jscholes]

Unfortunately, I don't think NVDA failing to complete a graceful shutdown is as much of an exceptional case as we'd like. That's not even NVDA's fault much of the time; what if Windows forces the app to close during a system shutdown before it's managed to complete the relevant steps? What if the user has changed their audio device configuration between starting NVDA and exiting?

Regardless, I'm not the intended audience for the feature, nor will I be writing or reviewing the code. Just wanted to share my opinion that this shouldn't be in scope right now. It makes it overly complex, and hence decreases the likelihood of it happening.

[lukaszgo1]

I agree NVDA should not restore the sound settings when closing, mainly because there is no guarantee that user did not change the volume / mute state from the Windows volume mixer after starting NVDA.

[CyrilleB79]

This issue is about doing automatically at NVDA startup what user manually do today after NVDA is started, that is:

• unmute the volume if it was muted
• modify the sound level according to their needs

Today after exiting NVDA, users do not re-mute the system if it was muted before. And it does not seem to cause big problems to sighted people using the computer after them.

So I also do not think that restoring the pre NVDA startup state is required, no matter the possible technical implementation issues.

[Adriani90]

I agree NVDA should not restore the sound settings when closing, mainly because there is no guarantee that user did not change the volume / mute state from the Windows volume mixer after starting NVDA.

That's a very fair point, thanks.

[LeonarddeR]

I agree NVDA should not restore the sound settings when closing, mainly because there is no guarantee that user did not change the volume / mute state from the Windows volume mixer after starting NVDA.

I'm not sure about this. When I start NVDA as a portable copy for example, NVDA is perfectly able to save the fact that it had to unmute the system, so I see no reason why it wouldn't restore that. Especially if I use someone's system who is used to muting his/her sound, I think it would be respectful if this setting is restored after NVDA has been closed. If not, I'd like the unmute at startup function to be opt-out.

[CyrilleB79]

I agree NVDA should not restore the sound settings when closing, mainly because there is no guarantee that user did not change the volume / mute state from the Windows volume mixer after starting NVDA.

I'm not sure about this. When I start NVDA as a portable copy for example, NVDA is perfectly able to save the fact that it had to unmute the system, so I see no reason why it wouldn't restore that. Especially if I use someone's system who is used to muting his/her sound, I think it would be respectful if this setting is restored after NVDA has been closed. If not, I'd like the unmute at startup function to be opt-out.

@LeonarddeR, have you read https://github.com/nvaccess/nvda/issues/3049#issuecomment-1992065206? This issue is about doing automatically what people would do manually without this feature. I understand the concern of being respectful by restoring the previous state (even if I doubt anybody does it when they manually unmute). But on the other side, in the case of re-muting after NVDA usage, the user who comes after the NVDA user may wonder why audio does not work anymore after having heard NVDA speaking.

Also,, the result of automatic unmute is quite obvious since NVDA immediately speaks. But the result of re-muting is not obvious since the silence after NVDA has exited may be due to nothing to be played or to audio being re-muted.

So to summarize, I do not support the re-muting implementation.

Regarding the default value of automatic muting, I agree that it should be opt in, since any modification of system parameters outside of NVDA should not be automatic.