Mixer war still: er hat sich selbst abgegriffen

Der Mixer gibt den Ton der bearbeiteten Programme selbst aus — und steht damit
als Tonquelle in seiner eigenen Liste. Eine Zeile wird geregelt, sobald man ihren
Regler anfasst. Ein Klick auf Onyx' eigene Zeile genügte also.

Der Selbst-Tap läuft wie jeder andere mit mutedWhenTapped und schaltet damit
Onyx' gesamte Ausgabe stumm — die Wiedergabe *aller* bearbeiteten Programme.
Völlige Stille, während die Pegelanzeigen weiter ausschlagen, weil die Taps ja
Signal bekommen. Und der Zustand stand in den Einstellungen, überlebte also
jeden Neustart.

Gemessen (Spikes/mixer-path-probe.swift): Onyx' Ausgabepegel klettert von 0,388
auf 2,833, sobald er sich selbst bearbeitet. Der Weg an sich ist in Ordnung —
Tap, Aggregate-Gerät und IOProc liefern einzeln wie zu dritt volle Pegel, das
war der Hauptverdacht und ist widerlegt.

Onyx erscheint jetzt nicht mehr in der eigenen Liste, lässt sich nicht auswählen,
und ein gespeicherter Eintrag wird beim Laden entfernt und zurückgeschrieben.

Dazu ein zweiter Fund aus derselben Ecke: setVolume und setMuted griffen auf
taps[bundleID] zu. Die Taps liegen aber unter Kennung#Prozessnummer, weil ein
Programm mehrere Tonquellen haben kann — der Zugriff ging immer ins Leere. Der
Regler wirkte erst, wenn die Auffrischung drei Sekunden später nachzog.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/spikes/C-audiotap.md

@@ -62,3 +62,58 @@ Vor Phase 7 zu klären. Bis dahin ist der Befund neutral festgehalten, nicht ent
 genannt wurden. Für die Notch-Shell in Phase 1 heißt das: mindestens eine davon greift
 denselben Bildschirmbereich ab. Für die Entwicklung sollten sie beendet sein, sonst überlagern
 sich Hover-Zonen und die Panels streiten sich um dieselbe Fläche.
+
+---
+
+# Spike C2 + C3 — der Wiedergabeweg (13.08.2026)
+
+Spike C hat nur zugehört: `muteBehavior = .unmuted`, kein einziges Sample zurück ans
+Gerät. Genau der ungeprüfte Teil war der, der im Betrieb still blieb. Werkzeuge:
+`Spikes/mixer-path-probe.swift` und `Spikes/multi-tap-probe.swift`, Testquelle ein
+eigens gebautes App-Bundle mit 440-Hz-Dauerton (`/tmp/OnyxTone.app`).
+
+## Der Weg selbst ist in Ordnung
+
+| Messung | Ergebnis |
+|---|---|
+| Tap `.unmuted`, ein Prozess | 469 Aufrufe/5 s, Spitze 0,366 |
+| Tap `.mutedWhenTapped` + Ausgabe über das Aggregate-Gerät | 469 Aufrufe/5 s, Spitze 0,366 |
+| Puffergeometrie | Eingang 1 Puffer / 2 Kanäle / 4096 Byte, Ausgang identisch |
+| Zwei Aggregate-Geräte gleichzeitig auf demselben Lautsprecher | beide 375+ Aufrufe, beide Spitze 0,366 |
+| Drei Aggregate-Geräte gleichzeitig | alle drei 375+ Aufrufe, alle Spitze 0,366 |
+
+Mehrere Geräte auf einem Ausgabegerät waren der Hauptverdacht — Chrome bringt
+mehrere Tonprozesse mit, also legt der Mixer mehrere Geräte an. **Der Verdacht ist
+widerlegt:** keines verhungert.
+
+## Der Fund: der Mixer greift sich selbst ab
+
+Sobald der Mixer ein Programm bearbeitet, gibt **er** dessen Ton aus. Damit steht er
+selbst in `kAudioHardwarePropertyProcessObjectList` — und in seiner eigenen
+Programmliste. Eine Zeile wird geregelt, sobald man ihren Regler anfasst. Ein
+einziger Klick auf Onyx' eigene Zeile genügt also.
+
+Was dann passiert, ist gemessen:
+
+| Zustand | Spitze der Onyx-Ausgabe |
+|---|---|
+| Onyx bearbeitet nur den Testton | 0,388 |
+| Onyx bearbeitet zusätzlich sich selbst | **2,833** |
+
+Der Pegel schaukelt sich auf, weil Onyx seine eigene Ausgabe wieder abgreift und
+erneut ausgibt. Entscheidend ist aber die andere Hälfte: der Selbst-Tap läuft mit
+`.mutedWhenTapped` und schaltet damit **Onyx' gesamte Ausgabe** stumm — also die
+Wiedergabe *aller* bearbeiteten Programme. Ergebnis: völlige Stille, während die
+Pegelanzeigen weiter ausschlagen, weil die Taps ja Signal bekommen.
+
+Und der Zustand steht in den Einstellungen: er überlebt jeden Neustart.
+
+**Abhilfe** (`ProcessVisibility.isExcluded`): Onyx erscheint nicht in der eigenen
+Liste, lässt sich nicht auswählen, und ein gespeicherter Eintrag wird beim Laden
+entfernt und zurückgeschrieben.
+
+## Nebenbefund
+
+Ein Tap sieht das Signal **vor** dem Stummschalten. Ein globaler Tap zeigt deshalb
+weiterhin den vollen Pegel eines bereits stummgeschalteten Programms — als Nachweis,
+ob das Stummschalten greift, taugt er nicht.