serrebi/NVDARemoteAudioClient
Watch
1
0
Fork
You've already forked NVDARemoteAudioClient
 0
mirror of https://github.com/serrebidev/NVDARemoteAudioClient.git synced 2026-10-28 16:06:41 -07:00
Code Issues Projects Releases 29 Packages Activity
29 releases 29 tags
  • v0.2.14 78b50a5936

    v0.2.14 Stable

    serrebi released this 2026-10-18 13:30:41 -07:00 | 1 commits to main since this release

    Downloads
  • v0.2.13 a5da8fb944

    v0.2.13 Stable

    serrebi released this 2026-10-14 16:29:11 -07:00 | 3 commits to main since this release

    Downloads
  • v0.2.12 44c3b0f67b

    NVDA Remote Audio Client v0.2.12 Stable

    serrebi released this 2026-10-03 19:56:17 -07:00 | 4 commits to main since this release

    Updated to .NET 10 and current dependencies

    • The helper now targets .NET 10 and its .NET packages are on their current
      releases, with the version pins removed. NAudio 3 needed an API migration, so
      the capture and playback paths were rewritten against it. Audio behaviour is
      unchanged; the relay protocol, the encryption, the quality modes and the user
      interface are all as before.
    • Installing needs the .NET 10 runtime. The helper is still self-contained, so
      an installed copy carries its own runtime and this does not affect it.
    • GitHub Actions moved to the current publisher releases, so their JavaScript
      runs on Node 24.
    Downloads
  • v0.2.11 5ae153774e

    0.2.11 Stable

    serrebi released this 2026-09-28 09:27:05 -07:00 | 10 commits to main since this release

    Group calls through a RemSound V2 relay

    • A RemSound relay running server v2.9 or newer can now carry a group of up to 64 devices that share one encryption password, instead of a single pair. This is the feature requested in issue #6.
    • Type the relay's address into the new RemSound relay for group calls setting. The relay stays an ordinary peer too: until its member list arrives, and if the lists ever stop, everything falls back to device-to-device behavior.
    • NVDA menu > Tools > NVDA Remote Audio > Choose RemSound relay members... opens a checklist of the group's members. Ticking works both ways, like the phone app: the relay only forwards audio between members that ticked each other, and a member marked "has ticked you" already has. Hear everyone returns to the whole group.
    • This computer announces itself to the relay every two seconds with a persistent group identity — 16 random bytes kept for the life of the installation — so the other devices keep recognizing it after a restart, and it says goodbye when the connection closes.
    • Changing the encryption password starts a new group on the relay: the saved member selections are dropped, here and there, and the next announcement hears everyone again.
    • Under the hood: audio, format, heartbeat and volume packets travel in group framing (the ordinary header with version 2 and the sender's client id) while the relay's member list is fresh; heartbeats also go out in ordinary form so a phone or an older app holding one of the relay's pair slots keeps working; the relay's address check is still echoed verbatim, never in group framing; group audio is keyed per member, and a member that leaves has its streams dropped at once.

    Testing

    • New TestRelayGroups in the helper self-test: group header round trip, ordinary/wrapped rejection both ways, the legacy 40-byte hello and the ticked hello layout, name truncation on a character boundary, bye, current and legacy roster parsing, malformed roster rejection, the 240.0.0.0/5 member addresses with collision handling, the 16-byte group audio budget, and group client id persistence, damage recovery, and all-zero rejection.
    • TestOptions gains the relay switches: --relay-ticks absent means the whole group, present-but-empty means an explicit empty list, and a bad id is rejected.
    • tools/selftest_addon.py: the RemSound command-line test passes a relay and tick list through; testRelayTickNormalization covers the None/empty/invalid/deduplicated cases and the single-relay rule; the event test feeds relay_members rosters and requires joins and leaves to be announced exactly once each, and silence when nothing changed.
    Downloads
  • v0.2.10 3da5bb18c8

    v0.2.10 Stable

    serrebi released this 2026-09-19 12:46:55 -07:00 | 14 commits to main since this release

    Install the same version on both computers, then restart NVDA.

    A Wired latency profile, for a sender on a cable

    Adds Wired: lowest latency, no room for Wi-Fi jitter to the latency profiles — the floor the helper accepts: 5 ms prebuffer, 5 ms WASAPI event-sync target, 60 ms cap, 5 ms Opus frames. That is roughly 10 ms less buffering than LAN.

    It is never chosen for you. Automatic still resolves to LAN, and only an explicit choice selects Wired. LAN keeps its settings, because a phone on Wi-Fi needs the room they keep — the live iPhone run at LAN settings already produced 88 underruns over 48 seconds, and tightening that would trade audible dropouts for a delay you cannot perceive.

    LAN's own label changes from "LAN: lowest latency" to "LAN: low latency", since Wired is now lower.

    Why it is a new option rather than a new default

    This came from a report of lag when sending to a television. Measured, the delay was not ours:

    • the Android receiver buffers 50 ms by default (its own UI can lower it), and
    • its audio output thread averaged 80 ms (ave=80.67 std=6.45 min=54.78 max=101.22 in dumpsys media.audio_flinger), while
    • our send path was already 5 ms Opus frames at a measured 200 packets per second.

    A receive-side buffer cannot help a device whose delay lives in its speaker path, so Wired is offered for the case it does help — a sender on the same cable — instead of being applied to everyone.

    Note too that latency profiles shape what this computer hears, not how quickly another device plays what this computer sends.

    Requirements

    • Windows 10 build 20348 or newer, or Windows 11.
    • NVDA 2025.1 or newer.
    • Peer to peer with RemSound: UDP port 47830 on both devices, plus UDP 47821 for discovery, and the same encryption password on both.
    • Through the audio server: TCP and UDP port 6838 reachable on the sending computer.

    Full notes: RELEASE_NOTES.md

    Downloads
  • v0.2.9 b1011cb61f

    v0.2.9 Stable

    serrebi released this 2026-09-19 12:34:37 -07:00 | 14 commits to main since this release

    Install the same version on both computers, then restart NVDA.

    A RemSound device can no longer change this computer's Windows volume

    Reported as "it turned up the volume when it did RemSound". There was a path that could do exactly that: with Let RemSound devices that share the password change this computer's volume ticked, an authenticated SystemVolumeUp from a peer reached SystemVolume.Apply and stepped your Windows master volume up. The switch was on, so nothing stopped it.

    That path is gone rather than gated:

    • Incoming system-volume commands are refused by a rule, not by a setting. The setting now allows only the volume of the audio a peer sends to you, which moves the gain on that stream and nothing else.
    • The helper no longer contains any code that sets an endpoint volume — no VolumeStepUp, no VolumeStepDown, no Mute write. A speaker volume that moves on its own cannot have come from a RemSound peer.
    • A refusal is logged with its reason, so it is never silent.
    • The renamed setting is Let RemSound devices that share the password change the volume of the audio they send here. The stored key is unchanged, so your settings and profiles still load.

    Sending those commands outward is untouched: this computer can still raise, lower, or mute the other device's volume from the NVDA Remote Audio gestures. That is you acting deliberately on the device in front of you.

    Requirements

    • Windows 10 build 20348 or newer, or Windows 11.
    • NVDA 2025.1 or newer.
    • Peer to peer with RemSound: UDP port 47830 on both devices, plus UDP 47821 for discovery, and the same encryption password on both.
    • Through the audio server: TCP and UDP port 6838 reachable on the sending computer.

    Full notes: RELEASE_NOTES.md

    Downloads
  • v0.2.8 93696a0ff0

    v0.2.8 Stable

    serrebi released this 2026-09-19 12:03:40 -07:00 | 16 commits to main since this release

    Install the same version on both computers, then restart NVDA.

    RemSound peer to peer is now the default connection type

    Connection type in settings still offers both, but a fresh install now starts on RemSound peer to peer, and it leads the list. RemSound is the connection that reaches a phone, a Mac, or a PC — one shared password, no server. The relay is now the specialist choice, for two Windows computers where the audio server is already installed.

    A configuration saved before the connection type existed is left on the audio server. Those users are already set up on the relay, and moving them to RemSound would leave them unable to connect at all, because RemSound requires an encryption password. The new default applies to a config that has not been written yet, not to one that predates the choice. An explicit choice is always honoured.

    What this does not change

    • The relay path: same payload v2, same ports, same room-name behaviour, same latency profiles.
    • The helper's own --transport command line default is still the relay, because the add-on passes --transport remsound explicitly when it wants RemSound and passes nothing otherwise. Changing that would break the relay path for a newer add-on paired with an older helper.
    • Existing RemSound installations: an explicit transport in the config is never overridden.

    Testing

    • tools/selftest_addon.py: 268 → 274 checks, covering the new default, the default being first in the settings list, an unknown connection type falling back, a pre-connection-type config staying on the relay with its settings intact, and a config-less install getting RemSound.
    • tools/mutation_check.py: 31 mutations, all caught — including one for a default that never changed, and one for an upgrade that silently moves a relay setup onto RemSound.
    • Verified live against the RemSound iPhone app: resolving the phone by name brought 24.3 seconds of its microphone back with every 100 ms window audible and zero authentication failures.

    Requirements

    • Windows 10 build 20348 or newer, or Windows 11.
    • NVDA 2025.1 or newer.
    • Peer to peer with RemSound: UDP port 47830 on both devices, plus UDP 47821 for discovery, and the same encryption password on both.
    • Through the audio server: TCP and UDP port 6838 reachable on the sending computer.

    Full notes: RELEASE_NOTES.md

    Downloads
  • v0.2.7 8e12c91196

    v0.2.7 Stable

    serrebi released this 2026-09-19 11:57:57 -07:00 | 17 commits to main since this release

    Install the same version on both computers, then restart NVDA.

    Choosing a RemSound device now says how to start it

    Choosing a device from Find RemSound devices on this network starts no connection by itself, and a RemSound connection that is not running is silent. On the RemSound phone app, ticking a peer is how you start listening — so anyone arriving from that app hears "Chosen: iPhone", waits for audio, and concludes the choice did nothing.

    This was reported exactly that way, from an NVDA debug capture of a real install: the device found and ticked, the password correct, the connection type set — and no connection ever attempted.

    The message now continues: that nothing is connected yet, and which menu item starts it. When audio is already running, the reminder is dropped, because reconnecting on a device change is the whole point.

    Reminder: choosing a device does not start the audio

    To start a RemSound connection, use NVDA menu > Tools > NVDA Remote Audio > Send and receive at the same time (RemSound) — or Receive remote audio or Send this computer's audio for one direction. Nothing connects by itself while Startup action is Disabled.

    Verified against the RemSound iPhone app

    Re-verified live through the path the add-on uses when you tick a discovered device: resolving the phone by name (--peer-names iPhone, no address) brought 24.3 seconds of the phone's microphone back to this computer with every 100 ms window audible, zero authentication failures, and zero unrecovered gaps.

    Requirements

    • Windows 10 build 20348 or newer, or Windows 11.
    • NVDA 2025.1 or newer.
    • Through the audio server: TCP and UDP port 6838 reachable on the sending computer.
    • Peer to peer with RemSound: UDP port 47830 on both devices, plus UDP 47821 for discovery.

    Full notes: RELEASE_NOTES.md

    Downloads
  • v0.2.6 23174aaf1d

    v0.2.6 Stable

    serrebi released this 2026-09-19 11:49:55 -07:00 | 17 commits to main since this release

    Install the same version on both computers, then restart NVDA.

    Choosing a RemSound device now says when a password is still needed

    RemSound always encrypts, so it can never connect without an encryption password. The settings panel already refuses to save a RemSound connection without one — but Find RemSound devices on this network is the one path that selects the connection type itself, and it performed no such check. Ticking a phone there switched the connection to RemSound, said so, and left the password empty, so every later attempt to connect was refused.

    Choosing a device now says, in that same spoken message, that RemSound also needs an encryption password and where to set it. The reminder appears only when a password really is missing: a RemSound setup that has one stays silent, and the relay path never mentions a password at all.

    This was found on a real installation, which is the worst way to find it: an add-on at the RemSound connection type, a phone chosen, no password, and the same "RemSound connections need an encryption password" on every start with nothing earlier tying the two together.

    If your RemSound connection will not start

    Open NVDA menu > Preferences > Settings > NVDA Remote Audio and fill in End-to-end encryption password with the same password the other device uses. RemSound has no unencrypted mode, so a RemSound connection with an empty password is refused before the helper is even launched — by design, and it says so when you try.

    Also check Startup action: on Disabled, nothing connects until you choose a role from the Tools menu.

    Verified against the RemSound iPhone app

    Re-verified live, including the path the add-on actually uses when you tick a discovered device: resolving the phone by name (--peer-names iPhone, no address) brought 24.3 seconds of the phone's microphone back to this computer with every 100 ms window audible, zero authentication failures, and zero unrecovered gaps.

    Requirements

    • Windows 10 build 20348 or newer, or Windows 11.
    • NVDA 2025.1 or newer.
    • Through the audio server: TCP and UDP port 6838 reachable on the sending computer.
    • Peer to peer with RemSound: UDP port 47830 on both devices, plus UDP 47821 for discovery.

    Full notes: RELEASE_NOTES.md

    Downloads
  • v0.2.5 e2ecee22aa

    v0.2.5 Stable

    serrebi released this 2026-09-19 11:38:18 -07:00 | 19 commits to main since this release

    Install the same version on both computers, then restart NVDA.

    This computer keeps one RemSound identity

    The helper announced a brand-new discovery instance ID on every start, so no other RemSound device could identify it across restarts. The iPhone app documents what that forces it to do, in its own source: a discovered peer is re-identified by IP address, because "the address is the only stable key". Everything you had set up for this computer was therefore tied to an address that can change.

    The identity is now kept once per installation and announced on every run, so a device that has this computer ticked keeps seeing the same computer — after a restart, and after this computer's address changes. A damaged identity file is replaced rather than announced, and a read-only profile or full disk falls back to a fresh identity per run instead of breaking audio.

    No wire-format change: packet layout, password handling, ports, and codecs are untouched, so nothing already set up is affected.

    Verified against the RemSound iPhone app

    Two-way audio with a real iPhone running RemSound was exercised over the LAN, in both codecs, sending a tone to the phone and recording the phone's microphone here:

    • Opus — 48.4 seconds recorded, every 100 ms window audible, zero authentication failures, zero unrecovered gaps, zero send errors, 2–3 ms round trip.
    • PCM — 39.4 seconds recorded, zero authentication failures, zero unrecovered gaps. The 24-bit multi-part frame reassembly had only ever been covered by self-tests; it is now confirmed against a different implementation on the other end.

    One thing worth knowing if a phone stays silent: RemSound on iOS does not send its microphone until that peer is ticked and sending is switched on. Both are on the phone, and the app's own per-device status text names which of the two is stopping it.

    Requirements

    • Windows 10 build 20348 or newer, or Windows 11.
    • NVDA 2025.1 or newer.
    • Through the audio server: TCP and UDP port 6838 reachable on the sending computer.
    • Peer to peer with RemSound: UDP port 47830 on both devices, plus UDP 47821 for discovery.

    Full notes: RELEASE_NOTES.md

    Downloads