Tell the server the volume we are actually applying

Reading Sendspin/spec settled the question I had parked for item 13, and not in
the direction I expected: this was never a behaviour change to weigh up, it was a
spec violation with a visible symptom we had already been staring at.

  - client/state's player `volume` MUST be included when a player advertises the
    `volume` command, which this one does.
  - "Group volume is the average of the volumes of players in the group that
    support the `volume` command." Group volume is *derived from us*. So the
    `group volume: 0` that confused this entire field test was our own misreport
    averaged straight back to us -- not a server oddity, ours.
  - Setting group volume works off "delta = requested_volume -
    current_group_volume", so a wrong figure mis-applies every later group volume
    change by exactly the error. A player claiming 0 while playing at full hears
    a request for 30 as a cut from full rather than a rise from silence, which is
    the symptom I had predicted without knowing the mechanism.
  - "A server MUST NOT assume these values are unchanged after a reconnect" --
    the player is the authority and the server depends on being told.

So main.cpp reports the sink's real gain before anything can connect.
update_volume() rather than reaching for the sink, because it does not invoke
on_volume_changed() -- that fires only for server-initiated changes -- so status
still tells a default apart from a volume a server chose.

Confirmed against the live server: group volume now reads 100 for a single player
at 100 where it read 0 before, and a following `vol 30` lands at a real 30 with
the default qualifier correctly gone.

Two deviations found in the same reading are left for item 13, now known to be
deviations rather than open questions: persisting volume and muted across
restarts is the spec's RECOMMENDED and needs item 8's store, and the software
taper is (volume/100)^2 where the spec says (volume/100)^1.5 -- roughly 3 dB
quiet at volume 50, 6 dB at 25, inherited from upstream and shared by both sinks.
The spec also says volume changes SHOULD be ramped, and nothing here ramps.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: chrisuthe

README.md

@@ -433,10 +433,16 @@ server does not re-report, the estimate drifts by however far you jumped. Paused
 it is the server's own snapshot and carries no marker.
 
 `player volume` is the gain **this box's output** is applying, and it says
-`(default; no server has set it)` until a server sends a volume command — because
-until one does, the sink runs at full while the library's own stored volume reads
-0. Those disagree, and the qualifier is how you tell "nobody has set this" from a
-server that deliberately chose full output.
+`(default; no server has set it)` until a server sends a volume command. The
+qualifier is how you tell "nobody has set this" from a server that deliberately
+chose full output.
+
+That figure is also what the server is told, from the first message — which the
+spec requires and which matters more than it looks: **group volume is the average
+of the players' volumes**, and setting group volume applies a *delta* against it.
+A player that reported a volume it was not applying would skew the group reading
+for every controller, and make the next group volume change land wrong by exactly
+that error.
 
 Two `status` lines are worth reading together. `state` is the **group's** transport
 state, from the metadata `playback_speed`, and reads `unknown` rather than guessing

docs/ROADMAP.md

@@ -740,13 +740,35 @@ caller of `set_volume()`, so the only thing that knows what the sink was told 
 distinguishable from one that never spoke. `DEFAULT_SINK_VOLUME` replaces the bare `{100}` the
 three sinks each spelled separately, with the disagreement written down beside it.
 
-**The underlying incoherence is left for item 13**, which already owns advertised state that does
-not match reality: we tell the server 0 while playing at full, so the first volume command a
-server sends is heard as a *cut* from full rather than a rise from silence. Fixing it means
-either seeding the role from the sink at startup (`update_volume(DEFAULT_SINK_VOLUME)`, which
-changes what we advertise) or seeding the sink from the role (which makes a fresh player silent
-until a server speaks). Both are behaviour changes wider than a control channel, and neither is
-this item's to make.
+**And the same disagreement was a spec violation on the wire, so it is fixed here too.** Reading
+`Sendspin/spec` settled which direction it had to go, and it is not a matter of taste:
+
+- `client/state`'s player `volume` **MUST** be included when a player advertises the `volume`
+  command, which this one does.
+- *"Group volume is the average of the volumes of players in the group that support the `volume`
+  command"* -- so group volume is **derived from us**, and a player reporting a figure it is not
+  applying corrupts the group reading for every controller in the group. The `group volume: 0` that
+  confused this whole field test was our own misreport averaged back to us, not a server oddity.
+- Setting group volume works off *"delta = requested_volume - current_group_volume"*, so that wrong
+  figure then mis-applies every later group volume change by exactly the error: a player claiming 0
+  while playing at full hears a request for 30 as a cut from full rather than a rise from silence.
+- *"A server MUST NOT assume these values are unchanged after a reconnect"* -- the player is the
+  authority and the server depends on being told.
+
+So `main.cpp` reports the sink's real gain with `player.update_volume(DEFAULT_SINK_VOLUME)` before
+anything can connect. `update_volume()` rather than reaching for the sink because it does not
+invoke `on_volume_changed()`, which fires only for server-initiated changes -- so `status` still
+tells a default apart from a volume a server chose. Confirmed against the live server: it now
+reports `group volume: 100` for a single player at 100, where it reported 0 before, and a
+subsequent `vol 30` lands at a real 30.
+
+**Two things still left for item 13**, both now known to be spec deviations rather than open
+questions. Persisting `volume` and `muted` across restarts is the spec's RECOMMENDED and needs a
+store, which item 8 owns. And the software taper is `(volume/100)^2` where the spec says
+*"`amplitude = (volume / 100)^1.5`"* -- about 3 dB quiet at volume 50 and 6 dB at 25, inherited
+from upstream's `PortAudioSink::apply_volume_()` and shared by both sinks through
+`src/pcm_volume.cpp`. The spec also says volume changes SHOULD be ramped to avoid clicks, and
+nothing here ramps.
 
 **Every command works, and finding that out took listening rather than reading.** An earlier pass
 concluded that `seek-rel`, `repeat` and `shuffle` were advertised and unimplemented at the server's

src/main.cpp

@@ -638,6 +638,26 @@ int main(int argc, char* argv[]) {
     player_config.audio_formats = advertised_formats(*sink);
     sendspin::PlayerRole& player = client.add_player(std::move(player_config));
     player.set_static_delay_adjustable(true);
+    // Report the gain the sink is really applying, before anything can connect.
+    //
+    // Not cosmetic, and not a preference -- three spec rules make it necessary. `client/state`'s
+    // `volume` MUST be included when a player advertises the `volume` command, which this one
+    // does. Group volume is *derived* from us: "Group volume is the average of the volumes of
+    // players in the group that support the `volume` command", so a player reporting a figure it
+    // is not applying corrupts the group reading for every controller in the group. And setting
+    // group volume works off "delta = requested_volume - current_group_volume", so that wrong
+    // figure then mis-applies every later group volume change by exactly the error -- a player
+    // claiming 0 while playing at full hears a request for 30 as a cut from full, not a rise.
+    //
+    // The library's own default is 0 while every AudioSink starts at DEFAULT_SINK_VOLUME, so
+    // without this the two disagree from the first message. update_volume() is the right call
+    // rather than reaching for the sink: it does not invoke on_volume_changed(), which fires only
+    // for server-initiated changes, so `status` still distinguishes this from a volume a server
+    // chose.
+    //
+    // Persisting volume and mute across restarts is the spec's RECOMMENDED and is deliberately
+    // not done here -- that needs a store, which docs/ROADMAP.md item 8 owns.
+    player.update_volume(DEFAULT_SINK_VOLUME);
     sendspin::MetadataRole& metadata = client.add_metadata();
     // Added unconditionally, so `client/hello` always carries `controller@v1` -- including under
     // --no-control, and including on a host with no $XDG_RUNTIME_DIR to put a socket in. That is