docs(issues): #0054 — way B implemented and live, gate closed, acceptance pending
Records the decision (per-track AudioContext instead of webAudioMix), the implementation state (v0.5.2, defaults never carry a processor key, dev-only opt-in via two localStorage keys), the discoverability stumble from the first test attempt, and the two-stage acceptance that gates opening the feature. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
755aa3f2b5
commit
fdb514d01d
@@ -296,3 +296,34 @@ gilt ab jetzt: **Abnahme im echten Call ist Rollout-Voraussetzung, nicht Nacharb
|
||||
**Offen (Folge-Entscheidung, nicht Teil dieses Issues):** Der Filter bleibt stillgelegt, bis
|
||||
`webAudioMix` entschieden ist — Upstream-TODO mit Nebenwirkungen auf Echo-Unterdrueckung und
|
||||
Ausgabegeraete-Wahl. Erst diese Entscheidung macht ADR-0018 umsetzbar oder widerlegt ihn.
|
||||
|
||||
## Weg B umgesetzt (2026-08-16/17): v0.5.2 live, Tor zu, Abnahme ausstehend
|
||||
|
||||
**Entscheidung sorb:** Weg B — AudioContext nur auf dem lokalen Mikrofon-Track
|
||||
(`LocalAudioTrack.setAudioContext()` unmittelbar vor `setProcessor()`), statt `webAudioMix`
|
||||
am ganzen Raum. Kleinster Wirkradius: Wiedergabe, Ausgabegeraete-Wahl und Echo-Verhalten
|
||||
bleiben unberuehrt.
|
||||
|
||||
**Umsetzung** (threadnet-call `df4e5ee`, embedded `.10`, ThreadNet-Web v0.5.2):
|
||||
- Anbindung in `Publisher.onLocalTrackPublished`, also erst **nach** der Publikation — ein
|
||||
scheiternder Filter kann das Entmuten per Konstruktion nicht mehr verhindern.
|
||||
- Verschaerfte Invariante: `audioCaptureDefaults` traegt in **keinem** Zustand einen
|
||||
`processor`-Schluessel mehr; Regressionstest deckt auch den Aktiv-Fall ab.
|
||||
- Tor bleibt zu; ein einzelner Test-Client aktiviert ueber zwei localStorage-Schluessel
|
||||
(`ai-noise-suppression-dev` + normale Einstellung). Die normale Einstellung allein bleibt
|
||||
wirkungslos. 77 Tests gruen ueber die beruehrten Suiten.
|
||||
|
||||
**Stolperstein aus dem ersten Testversuch:** sorb suchte die Filter-Einstellung in den
|
||||
Client-Einstellungen — die UI ist aber absichtlich hinter dem Tor versteckt, und sie sass
|
||||
auch vorher nicht in Element Web, sondern in den Einstellungen **im laufenden Call-Widget**.
|
||||
Der Testweg ist in dieser Phase bewusst UI-los (Konsole); ausserdem kein privater Tab
|
||||
(eigener, leerer localStorage) und harter Reload noetig. Fuer die Tor-Oeffnung notiert:
|
||||
die Wiederauffindbarkeit der Einstellung gehoert in die Anwenderdoku.
|
||||
|
||||
**Offen — Abnahme in zwei Stufen (Rollout-Voraussetzung fuer die Tor-Oeffnung):**
|
||||
1. Normaler Call zu zweit ohne Schalter: muss sich exakt wie v0.5.1 verhalten.
|
||||
2. Test-Client mit beiden Schluesseln: Konsole meldet den aktiven Filter, ~23 MB dfn3 laden
|
||||
erst beim Entmuten, Gegenseite hoert keine Tastatur, Entmuten funktioniert weiterhin.
|
||||
|
||||
Erst danach: Tor oeffnen + UI einblenden (v0.5.3). Alternativ bleibt Abbruch (Option C)
|
||||
jederzeit moeglich — v0.5.2 ist fuer alle Nutzer verhaltensgleich mit v0.5.1.
|
||||
|
||||
Reference in New Issue
Block a user