Three related features for NVDA Remote sessions:
The problem this add-on solves is doubled audio when you control one machine from another with NVDA Remote and you also have some way of carrying the controlled machine's sound back to where you are sitting. That second channel could be any tool that streams a remote machine's audio to your local speakers — a remote-audio app, Windows' Sound Forwarding, a virtual audio cable, anything along those lines.
In that arrangement NVDA Remote is already passing the controlled machine's speech across to your NVDA, so your local NVDA speaks every announcement. At the same time, the controlled machine's NVDA is also speaking through its own audio, and your audio-streaming setup is faithfully relaying that back to you a fraction of a second later. The two voices overlap, slightly out of sync, and the controlled machine becomes unusable.
You could just change the controlled machine's NVDA to a silent output device, but it is far too easy to forget to switch it back. Walking up to the controlled machine days later and finding no speech at all is worse than the doubled audio you were trying to fix in the first place.
This add-on silences the controlled machine's NVDA only while you are actively typing into it from elsewhere. The moment you press a key on the controlled machine itself, speech comes back. There is nothing to remember to switch back, because there is no manual switch — your own keystroke on the local keyboard is what turns speech off and on again.
The companion feature, keeping the synth settings ring on your own machine, fixes a related annoyance. When NVDA Remote is forwarding speech, the voice you actually hear is your local one. Changing rate, pitch, volume or voice ought to change your NVDA, not the remote one you can no longer hear. Without this add-on, those keys go to the remote and adjust nothing you can hear.
Install the add-on on both machines. Open the NVDA menu, choose Preferences, then Settings, then the Remote Speech Control category. Type the same password into the Password field on both ends. The password itself is never sent over the network — the add-on uses a one-way fingerprint of it to prove the two machines belong together. Even if someone could watch every byte of network traffic, they could not work out what your password is.
If you regularly control the same two machines from each other, you can save yourself the consent prompts using the two checkboxes described below. Both are unticked by default, which means every mute requires an explicit yes from each side the first time.
Shared secret between the two machines. It must match exactly on both ends, including case. Without a password on either side, the mute feature does nothing.
Controller-side setting. When ticked, your machine automatically asks the controlled machine to mute the moment a remote session connects, instead of popping a yes/no prompt on your side first. Default unticked.
Controlled-side setting. When ticked, your machine accepts mute requests straight away with no prompt on your side, and remote typing keeps working normally. When unticked, you get a yes/no dialog asking whether to allow muting, all remote typing is held back until you answer, and nothing is muted until you accept. Default unticked.
Controller-side setting. When ticked, the synth settings ring keys (move between settings, increase, decrease) adjust the voice, rate, pitch, volume etc. of your NVDA while you are remotely controlling another machine, instead of being sent across to the remote. Default unticked.
Controller-side setting. When ticked, pressing NVDA's report-battery hotkey (NVDA+Shift+B by default) while remotely controlling another machine reports your own machine's battery instead of forwarding the keystroke to the remote. Default unticked. See the "Battery status" section below for what changes once this is on.
Controller-side setting. Picks whether you hear the local machine's battery first, the remote machine's battery first, or only the local one. Greyed out until the checkbox above is ticked. Default: local battery, then remote.
When ticked, the add-on writes a running commentary of what it's doing into NVDA's main log: when sessions start, when mute requests come and go, when speech is muted or unmuted. When unticked, it only writes when something actually goes wrong. Either way, real problems are always recorded; the setting just controls how chatty the log is. Default ticked, because looking in the log is the main way to work out what went wrong if anything misbehaves.
Connect with NVDA Remote as usual. Within a second or two of the session coming up:
Once both sides accept, NVDA on the controlled machine is silent for as long as you are typing from the controlling machine. The moment anyone presses a key on the controlled machine itself, speech comes straight back — until the next keystroke from the controlling machine, which mutes it again. This back-and-forth is what is meant by "ping-pong".
Disconnecting the NVDA Remote session always unmutes the controlled machine automatically.
While the controlled machine is waiting for the person sitting at it to answer the consent prompt, all remote typing and braille input from the controller is held back. This is what makes consent meaningful — without it, the controller could just type yes on the prompt themselves over the remote connection. Only the local user's actual keyboard (or braille display, or whatever they have physically attached) can answer.
The controller's NVDA will announce "Waiting for remote user to allow mute. Remote input is paused." when the pause begins. After the local user answers, your typing flows again — and you'll hear the result announced ("Remote machine speech muted" or "Remote machine declined the mute request").
If you want to skip this pause entirely on a machine you own and remote into often, tick "Allow speech to be automatically muted by controlling machine" on that machine. With that ticked, mute requests apply immediately and no consent prompt ever happens.
Press NVDA+control+shift+m on the controlling machine, while you are actively typing into the controlled machine (i.e. you have used the NVDA Remote "Send keys" toggle, default F11, to direct your keystrokes to the remote), to mute or unmute the controlled machine's speech.
The hotkey just sends the request — there is no yes/no dialog on your side, because the hotkey press is itself your decision, and while you are typing into the remote your keystrokes are going there anyway and you could not interact with a local dialog. You will hear the result a moment later, when the controlled machine has acted on it — "Remote machine speech muted", "Remote machine speech unmuted", or "Remote machine declined the mute request".
If the controlled side has not ticked the auto-mute box, the person there is asked to consent to the mute (and remote input is paused on their machine until they answer). Unmute requests never prompt the controlled user — those take effect immediately.
The hotkey is intentionally controlling-side only. The controlled user has no equivalent hotkey by design and does not need one: pressing any key on the controlled keyboard already brings speech back via ping-pong, and to set a lasting mute they ask the controller to toggle it. The hotkey also does nothing when you are not currently sending keys to the remote (i.e. you have F11'd back to controlling your own machine); it will say "Not currently controlling a remote machine".
The hotkey can be changed. Open the NVDA menu, choose Preferences, then Input gestures, then look under the Remote Speech Control category.
NVDA's synth settings ring (the keys for moving between voice settings and turning them up or down — exactly which keys depends on which layout you have NVDA configured for) lets you cycle through synthesiser settings like voice, rate, pitch and volume, and adjust them. Without this add-on, those keys go across to the remote machine while you are remotely controlling it — useless, because you are listening to your own NVDA, not the remote's.
Tick "Synth settings ring adjusts this machine, not the remote" on the controller side and those specific keys stay local. All other keys still go to the remote normally.
If you are on a laptop controlling a remote desktop and you press NVDA's report-battery hotkey (NVDA+Shift+B on the default English layout), the chord normally goes across to the remote machine. The desktop has no battery, so it just answers "no system battery" — which is not what you wanted to hear.
Tick "Announce local machine battery status when querying battery from a remote session" on the controller side and that chord is intercepted on your machine instead. Depending on the order you pick:
The wording is exactly what NVDA would normally say — your laptop will read out percent, time remaining, plugged-in / unplugged just like it does outside a remote session — but the announcement is prefixed with "Local" or "Remote" so you can tell the two halves apart.
For the local-then-remote and remote-then-local modes to work, the other machine also needs this add-on installed and running. If the other end does not respond within two seconds — for example because it has an older version of the add-on, or the network is being slow — your own machine's battery is announced anyway so you are never left without an answer.
The chord NVDA uses for "report battery status" can be changed from NVDA's Input gestures dialog under System status. This add-on intercepts whatever chord is currently bound to it, not specifically NVDA+Shift+B, so customised hotkeys work the same way.
What this section is really about: who is allowed to mute your machine, and how strongly the add-on stops other people doing it.
Only someone who knows your password can ever mute your speech. The password itself never leaves either machine; the add-on uses a one-way fingerprint of it to prove the two ends belong together. The fingerprint is computed in a way that is deliberately slow — slow enough that even if an attacker somehow got hold of one, they could not work backwards to the password by trying every common word.
Every mute request the add-on sends includes that fingerprint plus a fresh random number and the current time. The machine on the receiving end checks the fingerprint matches, the time is recent (within thirty seconds), and the random number has not been used before in the same session. So even if an attacker recorded a mute request off the wire, they cannot just replay it later — the random number will already have been used, or the timestamp will be too old.
If anyone tries to mute you with the wrong password three times in a row, the add-on stops listening to mute requests from that connection for sixty seconds. There is no error visible on the wire, so an attacker cannot tell whether they got the password right or wrong.
Even if someone connects to your NVDA Remote channel without the right password, they cannot mute your speech: every mute request from them will fail the fingerprint check, silently. And even with the right password, if you have not ticked "Allow speech to be automatically muted", you still get the yes/no prompt before any mute takes effect — and the controller cannot answer that prompt themselves over the remote, because their typing is paused on your machine until you do.
The add-on writes its progress and any errors into NVDA's main log. Open the NVDA menu, choose Tools, then View log. Search for lines beginning rsc:.
Most of the running commentary is at info level, which means you only see it if Verbose logging is ticked in the settings panel. If you are reading the log to work out what went wrong and you are not seeing these lines at all, the most likely reason is that Verbose logging is off — turn it on, try the session again, and check the log a second time.
On a working session you should see, on each machine, a startup block that includes "starting up", "OS-level audio session mute armed", "WH_KEYBOARD_LL hook installed for ping-pong attribution", and "_remoteClient integration installed". (Yes, those line names look technical — they are the literal log messages so they are easy to search for.) When a session connects, look for "transport connected" and "announcing capability". When both sides have said hello to each other you should see "peer capability received". When the audio actually mutes or unmutes you should see "SetMute(True) applied to NVDA audio session" or "SetMute(False) ..." — those are the moments you should be hearing your speech go quiet or come back.
If muting never happens at all, by far the most common cause is the password being different on the two machines. Set it again on both ends and try.