The AMD bench's desktop: HDA controller choice, native rate, codec volume and the volume keys

Cargo.toml

@@ -118,6 +118,7 @@ members = [
     "system/shell",
     "system/soundserver",
     "system/soundserver/mixer",
+    "system/soundserver/resample",
     "system/soundserver/virtio-sound",
     "system/sshserver",
     "system/supervisor",

images/system.toml

@@ -71,11 +71,13 @@ receives = ["power"]
 # reaches: serving it makes the sessions its launches open the screen's, whose
 # packages may ask the person at it for a folder. `clipboard` is sent every copy
 # made in the session, and `vdagent` alone receives it. `input` is where a source
-# of keys and pointer reports reaches the owner of input, which it is.
+# of keys and pointer reports reaches the owner of input, which it is. `volume`
+# is soundserver's master level and mute, which the volume keys set and no
+# other row receives.
 [programs.compositor]
 service = true
 serves = ["compositor", "prompt", "clipboard", "input"]
-receives = ["soundserver", "filepicker"]
+receives = ["soundserver", "filepicker", "volume"]
 devices = ["framebuffer", "keyboard", "mouse"]
 starts = ["terminal", "files", "/apps"]
 login = true
@@ -92,7 +94,7 @@ devices = ["isa:0060,0064:1,12"]
 
 [programs.soundserver]
 service = true
-serves = ["soundserver"]
+serves = ["soundserver", "volume"]
 devices = ["hda-audio", "pci:1af4:1059"]
 syscap = ["rt"]
 

issues/a-metal-row-names-no-hardware-and-a-bench-without-it-reds.md

@@ -18,9 +18,6 @@ that most rows ride:
   NotFound`: the job claims the T14's I219, which that bench has not. The
   `claim_reuses_its_remapping_entry` and `claim_refused_without_remapping`
   rows read that job.
-- `test_rs_hda_client_stall` exited 101 on the null sink, which the
-  `hda_client_stall` row reads:
-  `issues/the-amd-bench-answers-on-two-hda-controllers-and-plays-on-the-null-sink.md`.
 
 That run asked for `blackbox_unclaimed_page` alone, which passed. An
 unfiltered `cargo test --test toyos-build -- --metal --metal-host

issues/cpal-backend-hardcodes-the-format.md

@@ -4,25 +4,14 @@ kind: defect
 opened: 2026-08-01
 ---
 
-# The cpal ToyOS backend hardcodes 44100/2ch/i16 and rejects everything else
+# The cpal ToyOS backend offers I16 alone
 
-soundd's resampler and channel-conversion paths are unreachable from any real
-client and therefore effectively untested. The backend also `assert_eq!`s the
-device rate against a compile-time constant, so changing the driver's rate
-aborts every cpal app.
-
-**`Drop`'s bound on soundd is built from copies the same way.** A dropped
-`Stream` waits for soundd to close its signal pipe for at most soundd's 5 ms
-fade, in whole periods, plus the 8 periods of the stream's ring: 1280 frames at
-44100 Hz (`RELEASE_WITHIN`). Past it, `Drop` refuses by name and returns. The
-fade (`toyos_mixer::ramp_frames`) and the ring depth (soundd's `slot_count`, see
-`issues/client-ring-depth-is-the-devices-pipeline-depth.md`) are copies:
-`StreamOpenResponse.slot_count` reaches `AudioStream::open` and stays private,
-and no message carries the fade. If soundd's fade grows or a device's pipeline
-deepens, the bound shrinks under what soundd needs, and a healthy soundd is
-refused. That part goes when `AudioStream` says the ring depth and the fade and
-the host derives `RELEASE_WITHIN` from them, which changes `sdk/toyos/src` and the
-audio protocol.
+cpal's ToyOS backend (`toyos-0.18.0`) takes its rate and its release bound from
+soundserver: `default_output_config` is the described device's,
+`supported_output_configs` is mono and stereo over the client range soundserver
+accepts, and `RELEASE_WITHIN` is derived from the fade, the ring and the device
+period (#877). Its sample format is still I16 alone: a client asking for any
+other format is refused.
 
 Deferred to the quiet-tree window, not neglected: editing that fork needs
 `.cargo/config.toml` path overrides, which redirect cpal for **every** agent in

issues/hda-has-no-jack-detection-volume-or-keys.md → issues/hda-has-no-jack-detection-and-nothing-persists.md

@@ -4,28 +4,20 @@ kind: track
 opened: 2026-08-03
 ---
 
-# HDA plays, but there is no jack detection, no volume control and no volume keys
+# HDA plays, but there is no jack detection and nothing persists
 
-The driver is built and audible on both QEMU and the T14: codec decoding and
-output-path selection are a pure crate, the register allowlist is in the kernel
-with soundd holding no physical address, and three guest gates stand on it. What
-was staged after that never started, and it is about 850 lines of greenfield
-blocked on nothing:
+The driver is soundserver's: codec decoding, output-path selection, the
+controller choice and the master are a pure crate, and the kernel lists and
+binds controllers. The master volume and mute are the codec's, served on
+soundserver's `volume` port, and the volume keys set them from the compositor
+(#877). What remains:
 
 - **Jack detection and routing.** `GET_PIN_SENSE` is spelled
-  (`lib/hda/src/verb.rs:107`) and nothing issues it — that constant is its
-  only occurrence in the tree. Still wanted: a poll on the presence bit, a
-  switch between the fixed speaker and the headphone pin, and a ramp across the
-  switch so it is not a click.
-- **Master volume and mute**, at the codec rather than in the mixer, and the
-  message to set it. Path setup already emits `SET_AMP_GAIN_MUTE` once per pin
-  and once per converter (`lib/hda/src/config.rs:89`, `:94`, `:109-117`), at
-  the amp's own `zero_db`; what is missing is a level anyone can change after
-  that, not the verb.
-- **Volume keys.** The premise was never established either — the diagnostic
-  that would say what the T14's keyboard sends for them was never committed.
-- **Persistence** of the chosen output and level, blocked on the kernel keeping
-  anything it enumerates (`issues/the-kernel-keeps-nothing-it-enumerates.md`).
+  (`lib/hda/src/verb.rs`) and nothing issues it. Still wanted: a poll on the
+  presence bit, a switch between the fixed speaker and the headphone pin, and a
+  ramp across the switch so it is not a click.
+- **Persistence** of the chosen output and the master level, blocked on the
+  kernel keeping anything it enumerates (`issues/the-kernel-keeps-nothing-it-enumerates.md`).
 
 **Two pieces of the shipped work are still owed a verdict.** The four HDA
 sections of the audio baseline were never recorded, so the HDA arm asserts harm

issues/hda-stream-format-test-takes-its-oracle-from-another-implementations-source.md

@@ -0,0 +1,24 @@
+---
+status: open
+kind: defect
+opened: 2026-10-13
+---
+
+# The HDA stream-format test takes its oracle from another implementation's source
+
+`lib/hda/src/stream.rs`'s `every_rate_linux_tabulates_encodes_to_the_number_linux_tabulates`
+holds the rate half of `SDnFMT` to a table copied from Linux's
+`sound/hda/hdac_device.c`, and its doc names the file. Root `CLAUDE.md` (#902)
+reads another implementation's source only clean-room, and `reviewer.md`'s
+**Fit** refuses a test whose oracle is another implementation's source.
+
+Found while #877 changed `lib/hda/src/config.rs` beside it; #877 does not touch
+`stream.rs`.
+
+Owner: `lib/hda`.
+
+## Exit condition
+
+The test's expected words are derived from the Intel High Definition Audio
+specification's stream-format table (base, multiplier and divisor bits), cited
+at the site, and no source, test or comment under `lib/hda` names Linux.

issues/the-kernel-keeps-nothing-it-enumerates.md

@@ -37,7 +37,7 @@ On top of retention, in dependency order:
    is taken by an HTTP GET demo that should be renamed `http` first, which is
    the owner's call.
 6. **Master gain, and `audio volume`** — see
-   `issues/hda-has-no-jack-detection-volume-or-keys.md`, which needs the
+   `issues/hda-has-no-jack-detection-and-nothing-persists.md`, which needs the
    same thing.
 7. **Adopting a disk from inside the guest**, so designation stops being a
    host-side whole-device stamp minted by the build system. Blocked on the

kernel/src/device.rs

@@ -228,7 +228,7 @@ pub fn try_claim(class: DeviceType, selector: [u64; 2]) -> Result<Arc<DeviceClai
             Ok(DeviceClaim::new(class, DeviceInfo::Acpi(info), claim))
         }
         DeviceType::HdaAudio => {
-            let (info, pcm) = crate::drivers::hda::info().ok_or(ClaimError::Absent)?;
+            let (info, pcm) = crate::drivers::hda::describe()?;
             let claim = Claim::acquire(class)?;
             Ok(DeviceClaim::new(class, DeviceInfo::Hda(info, shm(pcm)), claim))
         }