Comment 2 by jteh on 2011-03-09 06:15
Changes:
Changed title from "Browse and Focus sounds are too loud" to "Ability to adjust volume of sounds"

Comment 3 by aleksey_s on 2011-03-09 06:55
I think better would be if voice volume controlled the volume of whole NVDA, including beeps and sound effects. This may be addressed in my NVWaveEnhancements branch.

Comment 4 by KevanGC on 2011-03-09 06:59
What if you want to have the sounds quieter than the speech?

Comment 5 by jteh on 2011-03-09 07:03
I am totally against voice volume controlling volume of sounds. In that case, it shouldn't be voice volume and it should be moved out of voice settings. Anyway, the original request wanted separate control for this, as the user found the sounds too loud relative to the voice.

Comment 6 by aleksey_s (in reply to comment 5) on 2011-03-09 07:15
Replying to jteh:

I am totally against voice volume controlling volume of sounds. In that case, it shouldn't be voice volume and it should be moved out of voice settings.

Right, I didn't say it would be in voice settings.

Anyway, the original request wanted separate control for this, as the user found the sounds too loud relative to the voice.

Then we should consider separate control for beeps as well. My point is that there should exist a control which manages the whole volume, and individual adjustments should be possible also. What about sound effect factor and tones factor? this way user can adjust entire volume as well as tune, say, sound effects factor to be 80% of the entire volume.

Comment 7 by jteh on 2011-03-09 07:45
I can't help feeling adjusting both tones and sounds separately is unnecessary or confusing. Tones and sounds are both supplementary; i.e. they aren't the primary form of audio output and they serve roughly the same purpose. However, having the sounds volume relative to the overall volume does make some sense.

Comment by jteh on 2013-03-23 05:13
(In #3100) Duplicate of #1409.

Comment 10 by driemer.riemer@... on 2013-04-12 04:42
I have noticed that the sound of progress bars advancing gets louder and louder the higher it gets. A nice feature would be to dynamically adjust the volume according to the pitch of the progress bars. I have had the volume of progress bars adjust so much while moving that people ask me what that beeping noise is with the volume adjusted and headphones on.

Comment 11 by briang1 on 2013-04-12 07:53
Firstly, the apparent rising volume does not actually seem to be real. Load some bleeps into a sound editor and use a compressor on them. I'm thinking small speakers madke low frequences sound quieter in my view

with regard to matching sounds and voice. Really if you are going to do this then maybe the system sound and the voice sound are all you need. However in one case it will be a balance sound level with systems sound then the normal volume controll can be used for both. sound level for voices is different on different voices ands synths so I can understand the need to have some control.
I'm not sure if it needs more than now, or a use of the controls in a more sensible way to achieve the result.

Comment 12 by Q on 2013-04-12 13:09
This thing is becoming overcomplicated.
Jamie: The user indicated that the sounds were too loud relative to speech volume because they turned their speech down and then did something, I.E. going in to a form field which is shockingly, terribly loud.
The discussion of progress bar beeps becoming louder as they increase in pitch is quite valid, but I think belongs in a separate ticket, this is something else we can address but has nothing to do with an overall volume.

My proposal:
A single volume which controls any speech or NVWave sound, tone, whatever. If this doesn't work we can iterate further, but let's not overthink it and consequently not move on it for another couple years.
I'll begin work on this and submit a patch to this ticket once I've got it sorted out. Once that's done we can discuss other issues further. I recommend you guys open another ticket re the progress bar tones.

Comment 13 by jteh on 2013-04-24 02:18
Re-posting Q from nvda-dev so we don't lose this.

So I've created an initial implementation of this that seems to work. Now any sound played through nvwave.playWaveFile scales its volume to that of the synthesizer. It makes things like entering/exiting browse mode when your synthesizer is turned down much more tolerable.
The only issue with it is that, for a reason I have not yet been able to determine, the very first file played, start.wav, is not scaled. All subsequent files are. If anyone could offer any insight I'd really appreciate it.
A patch is available at:
https://dl.dropboxusercontent.com/u/995729/nvwave_volume.patch

Comment 14 by jteh (in reply to comment 12) on 2013-04-24 02:35
Replying to Q:

The discussion of progress bar beeps becoming louder as they increase in pitch is quite valid,

As noted in comment:11, I'm pretty sure they aren't actually louder. It depends on the frequency response of your listening equipment. With my decent headphones, higher beeps don't seem louder, but with my notebook speakers, they do, since my notebook speakers have crappy low frequency response.

but I think belongs in a separate ticket,

If there is actually an issue, yes, please file another ticket.

A single volume which controls any speech or NVWave sound, tone, whatever. If this doesn't work we can iterate further, but let's not overthink it and consequently not move on it for another couple years.

IN general, your proposal makes sense, but there are problems:

• Some users mightn't actually want this single volume control; e.g. if the synth they're using is particularly loud or soft relative to other synths.
• It's counter-intuitive for the volume in Voice Settings to affect other sounds. Also, that volume setting is synth specific. If you want this, it should be moved out of Voice Settings, but again, some users might want it left as it is now.
• If you do move it out of Voice Settings, it can't be adjusted from the Synth Settings ring, since that's only for synth settings.
• It's possible for a synth driver to be for a hardware synth or the like, in which case none of this makes any sense at all.

In short, the UI is the problem here and adapting it to fit this feature will require a great deal of change.

One option that was suggested is to a have a checkbox in the Synthesizer dialog named "Volume of NVDA sounds follows voice volume", "Link volume of NVDA sounds to voice volume" or similar. This is not entirely elegant, but it solves the problem in a fairly clear and intuitive way. It should probably be disabled by default to avoid confusion and so users understand what they are choosing to do.

Comment 15 by jteh (in reply to comment 13) on 2013-04-24 03:27
Replying to jteh:

So I've created an initial implementation of this that seems to work.

Actually, !WaveOutSetVolume seems to affect the volume of the entire application, even if I change the -1 you specify to self._waveout (which is the instance specific wave out handle). It may even affect the entire system in XP. This is problematic because synthesisers control their own volume (and we don't handle audio output for all of them). (Imo, MSDN doesn't document this properly.) This means the volume is reduced by more than intended.

Now any sound played through nvwave.playWaveFile scales its volume to that of the synthesizer.

This needs to affect tones as well, but I assume you hadn't gotten around to that rather than it being an oversight.

The only issue with it is that, for a reason I have not yet been able to determine, the very first file played, start.wav, is not scaled.

Here's what's happening:

1. playWaveFile sets the volume to, say, 30.
2. eSpeak loads and uses nvwave. The volume defaults to 100. nvwave sets the volume accordingly.
3. Because !WaveOutSetVolume affects the whole application, it just overrode the volume change in step 1.

Comment 17 by blindbhavya on 2014-11-03 17:45
Hi,
For a more advanced implementation, I propose:
Create an Audio Manager dialog box in the Preferences submenu.
On the initial screen, there should be a slider to change the volume of all NVDA sounds (such as browse mode and focus mode audio indications, progresss bar updates indicating beeps, sounds played on starting and exitting NVDA etc.)
Next there should be the Advanced button which opens up a dialog where you can customize the volume of each sound individually, depending on what suits you.
If this implementation is adopted, then probably all the check boxes in various Settings dialog to play certain sounds or not would no longer be required, because the slider of these individual controls when set to 0 anyways would disable those sounds.
Also, there should be some method by which you can test your volume modifications, when you are in the dialog itself, so you can decide on which volume suits you.
Just my suggestions...

This is still giving a terrible user experience for the default case in 2016.
I often turn down my synthesizer volume when I need to turn up my system volume to hear something quiet. If then an NVDA UI sound plays, it is actively painful.

Please stop hurting my ears.

I agree with this. I think there should definitely be an option to tie
the UI sounds to the speech volume.

On 1/13/2016 12:56 PM, Christopher Toth wrote:

This is still giving a terrible user experience for the default case in
2016.
I often turn down my synthesizer volume when I need to turn up my system
volume to hear something quiet. If then an NVDA UI sound plays, it is
actively painful.

Please stop hurting my ears.

—
Reply to this email directly or view it on GitHub
#1409 (comment).

I provided details on the problems with the current patch in these two comments. I don't have time to work on this right now, but I'm very happy to discuss if someone can propose a solution which deals with the problems I outlined.

Merely introducing another option in the Voice Settings dialog or the Synthesizer Settings dialog to configure both the sounds and tones of NVDA combined would suffice, in my opinion. An average user would not differentiate between NVDA's sounds, tones and beeps, and thus rolling all of their customizability into one control should not be restrictive at all. Splitting this proposed option into sounds and tones, on the other hand, may seem unnecessary clutter and an overkill for some. Upon reading the discussion on this ticket though, I reckon I agree that merging this proposal into the Voice Volume option itself would be counter-intuitive. Could this ticket, if possible, please also be prioritized since there seems enough demand for this facility viewing the number of other tickets it blocks or at least assigned a priority?

Its hard to prioritise this above the current core projects. The demand is clear, and this seems to be an important problem to solve. On the other hand, at this stage, it is not clear what the preferred UX or implementation would be. This makes the implementation cost high. I'll set this as a P3 for now. If we can become more certain about the UX and try to simplify the issue and thus the cost of implementing this then we may be able to make it a P2.

I would just like to put my point of distress.
I resuscitated the voice of the nvda to use the voices of windows onecore, this to be able to use the functionality of reading of the emugis.
The voice in Brazilian Portuguese is very low.
One thing that's bothering me a lot is how I had to add to the sound of nvda. The sounds of nvda were almost unbearable when wearing headphones.
So I would suggest almost that in the form of a plea (laughs), it would be a way of lowering the sounds of the nvda individually, so it could make the sounds low and the synthesizer's voice louder.
I would like to add two more points.
I went to do a lecture showing the assistive technologies, and I connected the sound of the computer in sound boxes, and the difference between the voice of the onecore synthesizer was low, in contrast to the sounds of the nvda, but within the settings of the nvda The voice volume is at 100%.
And finally, I was experimenting with Joseph Lee's Object Location Tones add-on (and I would like to congratulate him), the idea was great, and the possibility of finding out where each object on the screen was, there was not an idea Visual of how it was organized the screen of a computer, however I was almost obliged to disable the complement again for the reasons above, I had to increase the overall volume of the nvda due to low onecore voice, and the sounds of the nvda were almost unbearable mainly The beeps used in the snap-in, and the progress bars.
Many thanks for the great work, and the comments are just from a constant user of nvda.

A few thoughts:

• @derekriemer notes in Ability to adjust volume of sounds #1409 (comment) that the volume of tones (such as the beeps for progress bar updates) increases as it goes higher. This is undesirable since a user only expects the pitch to increase and the volume of the tones to remain constant. However, @Brian1Gaff's Ability to adjust volume of sounds #1409 (comment) and @jcsteh's agreement expressed in a later comment together suggest that this is a fallacy resultant of the varying frequency responses of different audio playback equipment. Derek, do you still maintain your original stand, or do you agree with Brian and Jamie's explanations? Regardless, as Jamie notes in Ability to adjust volume of sounds #1409 (comment), if this actually turns out to be an existent issue, it would require a new ticket.
• I am of the opinion that a single volume control for all NVDA (.wav) sound schemes should be controlled by one slider. While counter-intuitiveness may be a concern, placing this slider in the Synthesizer Settings dialog or in the Voice Settings dialog sounds equally fine to me. I do agree that the proposed sound volume option should be synth specific so that a user can customize the sound volume relative to the loudness of every speech synthesizer individually.
• According to me, the current Volume slider in the Voice Settings dialog could be renamed to Voice Volume and another slider named Sound Volume could be added. This would allow for it to be accessed by the Synth Settings Ring also.
• I am not too sure I agree with the implementation of or understand the need for a "Volume of NVDA sounds follows voice volume" option. This sounds unnecessary to me.
  As noted in @feerrenrut's Ability to adjust volume of sounds #1409 (comment), we must discuss the UX completely so as to facilitate this ticket's reprioritization to potentially a P2. CC @fernando-jose-silva @ctoth @Laughingthunder @LeonarddeR and others

From #1409 (comment):

going in to a form field which is shockingly, terribly loud.

I couldn't agree more, I am an accessibility developer and tester at PhET Interactive Simulations and I get a headache after just a few minutes because of the enter/exit forms-mode sounds. This would be a wonderful improvement to your amazing project! Thanks!

there was 12 years passed and no solution was done.
It is a bit uncomfortable to listen these sounds on a high volume like error sounds and beeps.
Maybe we can revisit overal thing, and provide a solution.
I can try to work on this, but before we should identify what we want to see.

I think I am with Derek, turning down speech volume should turn down sounds volume as well. otherwise the settings would be to granular and people would get overwelmed by having to adjust tones of volume settings depending on how many profiles they are using.

Maybe using other wav sounds with a softer texture would improve the user experience.

I propose to also change the checkbox "play sounds" in NVDA general settings to a list with checkboxes, where people can mute and unmute different sounds in NVDA, i.e. progress bar, browse and focus mode, start and exit. The individual sound muting settings are mainly changed on a global scale rather than on a specific profile.

I'm just sad that it's 12 years since the original bug report, I implemented something that would have at least worked, and we're still discussing this.

Rather than blocking patches that aren't perfect until a perfect solution has been developed, I feel this project would make far more progress if it were willing to iterate and make improvements as they came, even if they weren't perfect.

I know that for me, every time my ears are blown out by the inappropriately-loud form field sound when the speech volume is turned all the way down, I think negatively about this.

It would be a good idea to replace all NVDA Sound Output, in fact, using something like https://miniaud.io/

Then all sound volume could be unified and we wouldn't have to worry about odd quirks of WaveOut.

Whatever we end up doing, I hold this truth to be self-evident:
We don't need a million more options.

In the WASAPI backend in #14697, I've just added support for configuring specific audio sessions (007b6fc). Tones and wave files have been split into a separate "NVDA sounds" session, which means this volume can be set independently using the system Volume Mixer. Undoubtedly, this won't be good enough for some people, since it isn't configurable from within NVDA's own UI and it doesn't change with the volume of the voice. However, changing the two together isn't desirable for everyone either. And having too many options is difficult to maintain and too complex for some people. So we can't win whatever way we go. Regardless, this at least partially addresses the concern, since users will now have some way of adjusting the volume of sounds, even if they don't love it.

This change also makes it possible to set the session volume via nvwave, so a check box could be added to make the volume of sounds follow the voice volume if so desired.

Rather than blocking patches that aren't perfect until a perfect solution has been developed, I feel this project would make far more progress if it were willing to iterate and make improvements as they came, even if they weren't perfect.

There's truth in that. On the other hand, the only solution thus far would have suited one use case (tying sound volume to voice volume) and regressed another use case (users who absolutely don't want sound volume tied to voice volume). The comments on this issue have made it pretty clear that both use cases are real and not imagined. As it is, I suspect you're not going to like the solution I've come up with above because it doesn't tie the two together and because you have to open the system Volume Mixer to use it. It's not perfect, but at least it doesn't break people who depend on them remaining separate.

Whatever we end up doing, I hold this truth to be self-evident: We don't need a million more options.

And yet, as noted above, there are multiple use cases we have to address here, some of which negatively impact others. One person's "not perfect but workable" is another's "this breaks me on a daily basis".

NVWave still does not have a possibility to simply set a volume of sounds, not talking about adjusting it from an ui.

I have an addon and wanted to adjust volume of playWaveFile with my own addon UI but as i understand, nvwave doesn't have such possibility.

@ctoth Do you still have that patch around? I was searching on my pc such piece of code but unfortunately was not able to find and that dropbox link is not working anymore.

nvwave currently doesn't, but the WASAPI version of nvwave in #14697 now does. @ctoth's original patch only set the volume for the entire application, not individual streams/sessions. See #1409 (comment).

I agree with @XLTechie on the checkbox suggestion. Jamie huge thanks to you and the guys from NV Access for working on the audio output stuff, writing more than 1,000 lines of code in this project is really a huge talent. Really amazing.

@ctoth I understand totally your frustration. On the other hand, I also understand the developers who want to provide a solution that is really improving user experience and does not result in lots of additional issues or important functionalities being broken.
To be realistic, this is the nature of open source projects. Many people contribute to this project volutarily, and structural funding sources for open source projects is still a challenge, even in 2023. So imo even if we have to wait many years to see significant improvements in certain cases, it is really incredible how far this project came given the small team at NV Access and many people working in their spare time for this project.

I'd say don't loose your motivation, even when things take long time to happen. This is the only way we can stand out against purely commercial solutions that often do as much as open source solutions or even less.

Looking at all the comments here, I'm still not convinced that having this check box (once implemented) default to enabled is actually "what most people expect". This is largely because there is no guarantee that a given voice will have an equivalent volume to the sounds; see the comments above regarding some OneCore voices, for example. Thus, I think the correct approach here is to get the check box implemented, default it to disabled and then see where we land. This minimises risk while giving users an option if they want it.

Personally for me it does not matter will it be enabled by default or not.
Of course, from an nn-advanced user's view it would be better to make this checkbox disabled by default, but having this as an option is more than appreciated.

It would be better to find a way to implement concrete volume control in nvwave itself.
I understand @jcsteh said that it is now possible to control volume from system mixer, but having it controled from the code also would be great for winmm if wasapi won't be enabled by default for a while.

We need WASAPI for controlling both via the System Volume Mixer and via nvwave. It just isn't worth implementing it for WinMM at this point. The intention is now to get WASAPI enabled by default in alpha as soon as possible to get maximum possible feedback.

Yes, that makes sense if it will be enabled by default

@jcsteh - can this be closed given #14697 was merged?

This issue got a bit conflated. There were two requests here: the ability to control the volume of sounds in general, and the ability to link the volume of sounds to NVDA's speech volume. The former is implemented by #14697. The latter is implemented by #14896. Thus, I think this should be closed by #14896 for completeness.