From 44aac0fcdeb505a36387878bc62579f168a91abf Mon Sep 17 00:00:00 2001 From: Bernardo Magri Date: Thu, 16 Jul 2026 09:32:28 +0100 Subject: [PATCH] =?UTF-8?q?docs(agent):=20#138=20root-caused=20=E2=80=94?= =?UTF-8?q?=20our=20own=20reprobe=20restarts=20the=20graph=20under=20Chrom?= =?UTF-8?q?ium?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bernardo's hypothesis (pipewire restarts, Chromium never reconnects) is right, and the journal names the restarter: dock-audio.nix:153 runs `systemctl --user restart pipewire pipewire-pulse wireplumber` on every monitoradded (#100). Chromium's audio service does not reconnect, so it enumerates nothing — Meet's "no mic or speakers". Ordering across four boots is decisive, and Bernardo asked for exactly this check: restart-after-Chromium in both broken sessions (boot -3 14:06:49 → 14:07:52; boot -2 11:10:34 → 11:31:22), restart-BEFORE in today's working one (08:04:19 vs 08:03:55, a 24s miss). Hibernate is not the cause, only how a Chromium lives long enough to meet a plug event. Retiers off [human] — no repro needed, and it predicts a live one: dock/undock now should break Meet in this session. Fix is ours, not Chromium's: the graph restart is inherited from "the old working flake", never shown necessary, and repair_dock_cards already handles the parked- card case without it. Co-Authored-By: Claude Opus 4.8 --- agent/BACKLOG.md | 67 +++++++++++++++++++++++++++++++++--------------- 1 file changed, 47 insertions(+), 20 deletions(-) diff --git a/agent/BACKLOG.md b/agent/BACKLOG.md index 08b252f..f623b4c 100644 --- a/agent/BACKLOG.md +++ b/agent/BACKLOG.md @@ -211,29 +211,56 @@ scaled splash — the LUKS prompt especially, since a passphrase box half off the panel is the failure that matters. Pass = docked boot + shutdown centred on both heads; undocked unchanged. -### 138. `[human]` Google Meet reports no mic or speakers; Zoom is fine +### 138. Our dock-audio reprobe restarts PipeWire under running apps (Chromium loses its devices) -Bernardo 2026-07-16 (T14s, docked): Meet insists there is no microphone or -speaker even with the browser permission granted; Zoom calls work. What I -could rule out from the live session, so the fix pass does not re-tread it: +Bernardo 2026-07-16, refined by his own hypothesis (pipewire restarts → +Chromium never reconnects) — which the journal confirms, and names **our own +code as the thing doing the restarting**. Symptom: Google Meet reports no mic +or speakers in native Chromium; Zoom is unaffected; it did **not** reproduce on +a fresh boot, only after days of uptime + a hibernate. -- The audio graph is healthy — PipeWire 1.6.5 with 4 sinks and 5 sources - (`wpctl status`), and a live `Chromium input` client was already attached. -- Not a Flatpak sandbox: Chromium is the **native** nixpkgs build from the - template's `home.packages`. (Zoom, the app that works, is the Flatpak. - Brave — also Flatpak — holds `pulseaudio` + `xdg-run/pipewire-0` + - `devices=all`, so it would not fail this way either.) -- One oddity worth checking first: the default source is **`OBSBOT Meet SE - Digital Stereo (IEC958)`** — an S/PDIF *passthrough* profile on the webcam, - a strange default for a mic. A device that enumerates but cannot open is a - plausible route to Meet's "no devices" wording. +**Mechanism.** `modules/home/dock-audio.nix:153` — on every `monitoradded`, the +`reprobe` path runs `systemctl --user restart pipewire.service +pipewire-pulse.service wireplumber.service`. A full graph restart, on every +physical monitor plug (#100). Chromium's audio service does not re-establish +its PulseAudio connection when the server disappears under it, so it keeps +running with a dead one and enumerates nothing — hence Meet's wording, hence +"restarting Chromium fixes it". Zoom survives because it is a Flatpak that +reconnects, and because it is generally started fresh into an already-restarted +graph. **Hibernate is not the cause** — it is only how a Chromium survives long +enough to still be running when a plug event arrives; resume-while-docked then +generates the `monitoradded` that fires the reprobe. -`[human]` because it needs the failure in front of us: **which browser** were -you in (native Chromium, or the Brave Flatpak?), and with it open on Meet, -`chrome://media-internals` plus the device list under `chrome://settings/content/microphone` -would separate "Chromium enumerates nothing" from "Meet rejects what it is -offered". Until then there is no way to tell a Nomarchy defect from a -device-profile accident, and guessing costs more than asking. +**Evidence — ordering is the whole tell** (`Started app-org.chromium.Chromium-*.scope` +vs `reprobe-start`, four boots, no exceptions): + +| Session | Chromium | Graph restart | Order | Meet | +|---|---|---|---|---| +| boot -3 (Jul 14→15) | 14:06:49 | 14:07:52 (+2 more; then 10:52 next day) | **after** | broken | +| boot -2 (Jul 15 daytime) | 11:10:34 | 11:31:22 | **after**, +21 min | broken | +| boot 0 (Jul 16, fresh) | 08:04:19 | 08:03:55 | **before**, −24 s | works | + +Today is the negative control, and it is luck, not a fix: the restart missed +Chromium by 24 seconds. **Prediction that confirms this outright — dock/undock +now, then reload Meet: it should break in the current session**, with no reboot +and no hibernate. That is the cheap V3 for the diagnosis, and it is also the +regression test. + +**What to fix.** Not Chromium — the graph restart is a sledgehammer we +inherited: the header comment justifies it only as "the recovery used by the +old working flake", i.e. it was never shown to be *needed*, while its collateral +(every long-lived audio client dropped) was never priced. It is also not rare — +boot -3 took three restarts in 82 seconds (14:07:52 / 14:08:58 / 14:09:09; +the `mkdir` debounce only collapses events within one run, not a plug storm), +and each one drops audio for every app on the machine. Shape: **try selection +first, restart only if nothing routable appears** — `select_first_dock` already +falls back to `repair_dock_cards`, which fixes the parked-card case +(`set-card-profile`) *without* touching the graph, so the restart may have no +remaining job at all. If some HDMI codec really does need it (the other claim +in that comment), prove it on this hardware and scope the restart to that case. +Pass = plug/unplug the dock with Chromium open → output still follows to the +monitor **and** Meet still sees its devices; `journalctl -t nomarchy-dock-audio` +shows no graph restart on the ordinary path. ### 139. Terminal floats open full-screen — % size rules are ignored, and Kitty remembers