You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
authored
feat(audio-mixer): honor ramp_ms on mute toggles, with cancel-guard (#540)
Mute toggles previously hard-coded MUTE_ANTICLICK_RAMP_MS (10 ms), so
external callers (Open Live, MCP) sending PATCH `.../mute` could not
request the broadcast-style 500 ms route fade they need for on-air /
off-air transitions. The volume path already honored `ramp_ms`; this
brings parity to mute.
Backend:
- properties.rs: mute branch passes `ramp_ms.unwrap_or(MUTE_ANTICLICK_RAMP_MS)`
into apply_mute, matching the volume branch.
- volume_ramp.rs: rename anticlick_ms -> ramp_ms in apply_mute. Add a
per-element generation counter (Arc<Mutex<HashMap<String, u64>>>)
so the tokio-scheduled `set_property("mute", true)` aborts on fire
if a later apply_mute call has bumped the generation. Without this,
a fast unmute mid-fade would still let the stale mute=true land
afterwards and silently kill the route. clear() also bumps every
generation so a stopped pipeline cannot be re-muted by leftover
scheduled toggles.
API:
- UpdatePropertyRequest.ramp_ms doc now covers `mute` and points at the
500 ms broadcast use case. OpenAPI snapshot regenerated (also picked
up the pending 0.4.12 -> 0.4.13-dev version bump).
Tests:
- long_mute_ramp_takes_full_duration: 200 ms fade-out must keep
audible level mid-ramp and only set mute=true after the full
duration + grace.
- unmute_during_long_mute_fade_cancels_pending_toggle: regression for
the cancel-guard — an unmute 40 ms into a 200 ms fade must prevent
the stale mute=true from landing 200 ms later.
- All existing volume_ramp + pipeline_lifecycle tests still green.
Usage example: `PATCH .../elements/<flow>:mixer:to_main_vol_<ch>`
with `{ property_name: "mute", value: true, ramp_ms: 500 }` now
produces a 500 ms dB-linear fade-out before mute=true lands; the
matching `value: false, ramp_ms: 500` produces a 0->pre_mute fade-in.
Co-authored-by: Per Enstedt <per.enstedt@svt.se>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: openapi.json
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@
10
10
"license": {
11
11
"name": "MIT OR Apache-2.0"
12
12
},
13
-
"version": "0.4.12"
13
+
"version": "0.4.13-dev"
14
14
},
15
15
"paths": {
16
16
"/api/auth/status": {
@@ -9885,7 +9885,7 @@
9885
9885
"null"
9886
9886
],
9887
9887
"format": "int32",
9888
-
"description": "Optional ramp duration in milliseconds. Currently only honored for\naudio `volume`-element `volume` updates — when set, the value is\ninterpolated per-sample over the given duration to avoid zipper\nnoise on fader drags or to match an auto-transition duration.\nWhen omitted, a short default ramp is used for `volume`; other\nproperties are set immediately.",
9888
+
"description": "Optional ramp duration in milliseconds. Currently honored for audio\n`volume`-element `volume` and `mute` updates — when set, `volume` is\ninterpolated per-sample over the given duration (anti-zipper / fade)\nand `mute=true` is preceded by a fade-out of the same length while\n`mute=false` is followed by a 0→pre_mute fade-in. Useful for\nbroadcast-style on-air / off-air route transitions (e.g. 500 ms).\nWhen omitted, a short default ramp is used for `volume`/`mute`; other\nproperties are set immediately.",
0 commit comments