Instead of webAudioMix on the room - which would also rewire playback (sink
selection through the AudioContext, LiveKit's Chrome echo workaround) - only the
local microphone track gets an AudioContext, via setAudioContext() right before
setProcessor(). The attach happens in onLocalTrackPublished, so a failing filter
can no longer prevent unmuting: the track is already published by then.
audioCaptureDefaults now never carry a processor key in any state; the
conditional spread only toggles noiseSuppression. A regression test covers the
active case too.
The gate stays closed. A single test client opts in via two localStorage keys
(ai-noise-suppression-dev plus the regular setting); the regular setting alone
stays inert. Four unit tests pin the attach order - setAudioContext before
setProcessor is exactly what v0.5.0 lacked - and the containment of a failing
attach. 77 tests green across the touched suites.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
threadnet.8 broke unmuting in production, both ways. With the filter on, LiveKit
refuses the processor because the room is built without webAudioMix, so no local
track ever carries an AudioContext. With the filter off, the options builder
still emitted processor: undefined and rewrote noiseSuppression - LiveKit copies
every key of audioCaptureDefaults into the getUserMedia constraints, undefined
included, and Safari stopped unmuting over it.
The off-path is now a conditional spread that produces an object identical to
upstream: no processor key at all, noiseSuppression untouched. Two regression
tests pin this down and were demonstrably red on the old code.
The feature itself is hard-gated off (AI_NOISE_SUPPRESSION_AVAILABLE) until the
webAudioMix decision is made and tested in a two-person call. The gate also
neutralizes clients that enabled the setting before - that state lives in
localStorage and survives every deployment. The settings UI hides behind the
same gate.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Element Call reaches production only as the embedded npm package, which webpack
copies into ThreadNet-Web under /widgets/element-call/. The embedded build sets
publicDir: false — upstream reasons that public/ holds nothing but the favicon,
which stopped being true when the model assets landed there.
Verified rather than assumed: with the upstream value everything builds, the
standalone bundle works, and the filter is dead only inside the widget, 404ing on
the model. That is the failure this would have shipped.
The package grows from about 41 to 66 MB, measured — most of what was already
there is source maps and the crypto and vision wasm.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0.19.2-threadnet.6 liegt mit 12,5 KB statt 12,8 MB in der Registry: package.json und Lizenzen, kein dist/. Woher der Upload kam, laesst sich nicht mehr klaeren - beide publish_npm-Laeufe von heute sind fehlgeschlagen, der eine vor dem Upload am fehlenden dist-tag, der andere danach mit 409. Die Nummer ist verbrannt, npm-Versionen sind nicht ueberschreibbar.
Der neue Check bricht ab, wenn embedded/web/dist weniger als 50 Dateien hat (erwartet ~150). Das kostet nichts und verhindert, dass diese Klasse Fehler noch einmal eine Versionsnummer verbrennt.
Registry-Entscheidung evidenzbasiert: das Package ist pnpm-Dependency von
ThreadNet-Webs apps/web, der Lockfile pinnt die Tarball-URL auf rohana -
Registry bleibt dort. Publish-Auth ueber CI-Variable GITEA_NPM_TOKEN statt
lokaler Klartext-.npmrc.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Thore CimbalandClaude Opus 4.8