Don't change the receiver's volume when audio is disabled

[josiahbryan]

The bug

-no-audio sets the receiver's volume to maximum on every connect.

volume: 0.000000 is 0 dB, which is full scale. setupMirrorSession sends it unconditionally, twice, so a session that streams no audio at all still commands the receiver to maximum and discards whatever the user had set. Reconnecting a dashboard or a mirrored window resets a TV's volume to 100 each time.

Not the same as #11

I want to be clear about this up front, because #11 set volume: 20.000000 and 5f14b6f reverted it — correctly. Positive dB is out of range and receivers may read it as zero gain, so picking a quieter number is not a fix.

This PR does not pick a number. It declines to send a volume at all when the session carries no audio. When audio is enabled, the 0 dB behaviour from 5f14b6f is untouched.

Also: the daemon's mute control

SetAudioMuted has the same effect one click away, and it is reachable in exactly the case this PR is about.

daemon.go deliberately routes mute/unmute to the receiver when audio is disabled:

if t.session != nil && (d.cfg.NoAudio || t.session.HasAudio()) {

and unmuting sends audioVolumeBody(false) — the identical full-scale value. A no-audio session still negotiates an audio stream, so HasAudio() is true and the plasmoid offers a mute toggle for a video-only session: first press silences the receiver, next press sets it to maximum.

So HasAudio() cannot distinguish the two modes. The guard reads MirrorSession.noAudio, which until now was assigned and never read.

Why skipping is safe

A session that transmits no audio has no use for the receiver's audio state. The request also sits after RECORD, so it is not part of the handshake, and this repo's own receiver treats SET_PARAMETER as a bare OK with no state transition.

I considered echoing the receiver's own reported volume back instead. On the Roku Streambar Pro I tested, initialVolume from /info stayed at 0.0 across ten VolumeDown and six VolumeUp presses, so it does not track that receiver's current volume and sending it back would still command full scale. Other receivers may report it faithfully — I only have the one device, so I did not build on it.

Tests

TestSetupMirrorNoAudioStillNegotiatesAudioSession asserted the two volume SET_PARAMETERs as part of the expected RTSP sequence for a no-audio session, and it was the only test covering that sequence — so updating it alone would have left nothing asserting that audio sessions still set the volume.

The shared helper is now parameterized over noAudio, with a named test per direction, plus one for the mute guard.

Each was checked against a mutation rather than just observed green:

• revert the setup guard → the no-audio test fails
• make the skip unconditional → the with-audio test fails
• invert the condition → both fail
• remove the SetAudioMuted guard → the mute test fails

Worth noting for anyone touching that harness: what actually pins the volume: 0.000000 payload is the fake receiver's body check, not the method sequence, and a mismatch there surfaces as a 5-second /feedback timeout rather than a useful message.

gofmt, go vet and go test ./... are clean, verified on a clean checkout of the commit rather than a working tree.

Verified on hardware

Roku Streambar Pro, model 9101R2:

-no-audio    [SETUP] no-audio session: skipping SET_PARAMETER volume
with audio   [SETUP] SET_PARAMETER volume=0 sent

Volume left untouched in the first case, unchanged behaviour in the second.

Scope

I deliberately did not touch the plasmoid, which still shows a mute toggle for video-only sessions — it now fails with a clear error instead of changing the volume. Hiding the control would mean changing what has_audio reports, which felt like a bigger decision than this fix. Happy to follow up if you'd prefer it gone.