audio

Host build proof: nix build .#handheld-shell-rust and the full k230-coherent-shell system closure cross-build succeed with systemd.services.pipewire/wireplumber/pipewire-pulse present in the closure. Host/build proof only -- whether these units actually reach active on the board is a separate, open task (see tasks.md); no task here claims that from a host build.

When k230.shell.coherentShell is enabled, the system SHALL run pipewire, wireplumber and pipewire-pulse as plain systemd system services under the shell user, bound to shell.service's own lifecycle, and SHALL install the PipeWire ALSA-compat plugin files so an existing plain-ALSA client (mpv, unchanged) is transparently redirected through PipeWire. No additional daemon beyond these three SHALL be added for this purpose.

Host build proof: cargo test/cargo clippy --all-targets for nix/rust-shell-client pass; slider.rs's floor-parameterized functions (clamp_percent_with_floor, value_at_x_with_floor, Drag::start_with_floor) and volume.rs's own unit tests cover the mapping, clamping and drag-to-mute behavior below. These are host/build proofs only; see the open real-finger task for physical acceptance.

The Settings screen and the pull-down shade SHALL each present a volume control directly under the existing brightness slider, using the same shared Material-3-style track/thumb component (slider.rs) rather than a forked copy. Unlike brightness, the volume slider's floor SHALL be 0 (true silence is a reachable value); a drag to the very bottom SHALL engage mute, and a drag anywhere above 0 SHALL clear mute and set the level, matching Android's own slider. A tap on the leading speaker glyph SHALL toggle mute without changing the remembered level, so unmuting restores the level active before the mute.

Host build proof: volume::tests::percent_to_linear_is_cubic_not_linear and linear_to_percent_round_trips_percent_to_linear (unit tests only); docs/evidence/volume/wpctl.md records the live wpctl/pw-dump capture this curve was checked against on a development host (not this board).

A UI slider percent SHALL map to a linear PipeWire volume amplitude through linear = (percent/100)^3 (and the exact inverse when reading a linear value back to a percent for display), not a straight linear map. This SHALL hold both for this shell's own throttled live-drag writes (which set channelVolumes directly and so must compute this curve themselves) and be consistent with wpctl set-volume's own percent argument, which already applies the same curve internally.

Host build proof: pipewire_ipc::tests::writer_handle_delivers_commands_ in_order_to_a_real_child_process spawns a real child process (a test double, not pw-cli itself) and confirms ordered delivery over a real pipe; set_volume_command_formats_a_scriptable_pw_cli_line covers the exact command text. Host/build proof only.

While a volume slider drag is in progress, the system SHALL send writes at roughly the same throttled cadence the brightness slider already uses (slider::LIVE_WRITE_INTERVAL_MS), each written to one already-running pw-cli child process's stdin (no process spawned per write), never blocking the Wayland/UI thread. The drag's release SHALL always send one additional, authoritative wpctl set-volume ID <percent>% call regardless of the live-write throttle's own timing, so the committed value is always the one wpctl itself computed and PipeWire/WirePlumber actually holds.

Host build proof: pipewire_ipc::tests::a_delta_that_only_touches_one_ node_does_not_wipe_the_others, a_removal_delta_drops_only_the_named_ object, and the fixture-replay tests against tests/fixtures/pipewire/* (captured-shape JSON, not live board output) all pass. Host/build proof only -- see the open task for whether this board's own WirePlumber actually names its sinks/streams the way these fixtures assume.

The system SHALL run one persistent pw-dump --monitor process for the life of the shell session and apply every array it prints -- the initial full dump and every subsequent per-change delta -- onto one running graph model, never discarding a sink or stream a given delta did not itself mention. An object reported as {"id": <id>, "info": null} SHALL be removed from that model. The shade's and Settings' own sliders, the HUD, and the expanded per-stream panel SHALL all reflect this same running model, so an external app, wpctl from a console, or a hardware key changing the default sink's volume or mute state is shown without polling.

Host build proof: volume::tests::hud_is_hidden_until_shown_and_ autohides_after_its_window, hud_toggle_expand_flips_state_and_refreshes_ the_timer, hud_drag_is_owned_by_the_touch_that_started_it, and change_origin_only_the_own_slider_suppresses_the_hud all pass. QEMU capture: docs/evidence/volume/ shows the HUD collapsed and expanded. Host/QEMU proof only -- see the open real-finger and hardware-volume-key tasks.

A hardware/keyboard volume key or any external PipeWire graph change to the default sink's volume/mute SHALL raise a vertical pill HUD on the panel's right edge; a drag on the shade's or Settings' own volume slider SHALL NOT, since that slider is already its own visible feedback (mirroring the brightness slider's own commit-toast suppression). The HUD SHALL auto-hide about 2.5 seconds after its last change, SHALL be draggable along the edge, and SHALL expand via a "…" affordance into a per-stream list: one row per PipeWire Stream/Output/Audio node, each with its own slider, and the app's name and icon where application.name/application.icon-name are present, falling back to the node's own name.