From 6d69782f381b33df23a486bf179f41671a941ee8 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Mon, 17 Aug 2026 12:00:00 +0000 Subject: [PATCH] =?UTF-8?q?docs(issues):=20#0054=20=E2=80=94=20Safari=20se?= =?UTF-8?q?nt=20unfiltered,=20fixed=20and=20verified=20in=20v0.5.4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit LiveKit's setProcessor swaps the sender track behind an optional chain; when Safari's timing leaves the sender unset at that instant, the swap is skipped silently and the raw microphone stays on the wire. The fork now verifies and enforces the swap. Also records two instructive diagnostic dead ends: a sine tone is noise to a speech model, and two devices in one room invalidate any listening test. Co-Authored-By: Claude Opus 4.8 --- ...ki-geraeuschunterdrueckung-element-call.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md b/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md index 4da4867..92761e5 100644 --- a/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md +++ b/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md @@ -327,3 +327,34 @@ die Wiederauffindbarkeit der Einstellung gehoert in die Anwenderdoku. 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. + +## Nachtrag 2026-08-17/18: Safari sendete ungefiltert — behoben in v0.5.4 + +Nach der Tor-Oeffnung (v0.5.3) meldete sorb: Filter wirkungslos, **Staerke 0-100 ohne jeden +Unterschied**, sauberer Alleintest (Hoergeraet gemutet). Auf anderen Rechnern (Chromium-Familie) +funktionierte derselbe Stand. Messungen mit einem lokalen Pruefstand (Playwright, echter +LiveKit-`setProcessor`-Pfad, Sprachsignal mit Klick-Transienten) ergaben: Prozessor und Modell +arbeiten korrekt — Sprache passiert, Klicks verschwinden. + +**Ursache:** LiveKits `setProcessor` tauscht den Sender-Track per +`this.sender?.replaceTrack(processedTrack)`. Ist der Sender in dem Moment nicht am Track +(Safari-Timing beim LocalTrackPublished-Event), wird der Tausch **stumm uebersprungen** — der +Prozessor laedt seine 23 MB, meldet Erfolg, und das rohe Mikrofon bleibt auf der Leitung. +Viertes Vorkommen des Sitzungsmusters "meldet Erfolg, ist aber blind", diesmal in Fremdcode +(das `?.` verschluckt den Fehlschlag). + +**Zwei Irrwege der Diagnose, festgehalten weil lehrreich:** +- Ein synthetischer Sinuston als "Stimme" liess den Filter wie einen Totalausfall aussehen — + fuer ein **Sprach**-Modell ist ein Ton Rauschen, die Daempfung bis zum Limit war korrektes + Verhalten am falschen Signal. Messsignale muessen dem Modell entsprechen. +- Zwei Geraete im selben Raum machen jeden Hoertest wertlos (Tastatur akustisch und ueber das + zweite, ungefilterte Mikro hoerbar). Der brauchbare Alleintest: Hoergeraet **gemutet** mit + Kopfhoerer. + +**Fix (threadnet-call `fee9866`, embedded `.12`, ThreadNet-Web v0.5.4):** Nach dem Anhaengen +wird verifiziert, dass der RTCRtpSender den gefilterten Track traegt — notfalls wird auf den +Sender gewartet und der Tausch explizit erzwungen. Die Konsolen-Zeile weist den Zustand aus: +`Sendepfad gefiltert: ja/NEIN`. Drei Tests decken die Sender-Faelle ab. + +**Test sorb 2026-08-18 (Safari als sendender Client): bestanden.** Damit ist der Filter auf +beiden Engine-Familien nachgewiesen. Weiterhin offen und bewusst vertagt: Telefontest (mobil).