fix(liveaudiorouter): show the bus its consumer's format before input

[wagenet]

Opened by Claude (AI) on behalf of @wagenet.

Fixes the intermittent not-negotiated failures in liveaudiorouter_test.rs on Check (Linux): a_routing_change_moves_audio_between_output_channels_while_playing (runs 36216640907, 36123655314) and closing_every_crosspoint_silences_the_output_without_a_silence_source (run 36143990431). The cause is in the block.

Cause

With its fader and soft clipper off, the output bus (audiomixer) takes its sample format from its first input. If it negotiates before any input has caps, it asks downstream. That caps query passes through capssetter_out_O, and capssetter answers an upstream caps query with the query's own filter, or ANY. It never reports what is downstream of it. So the mixer picks its default, S32LE at 44100 Hz, and a consumer that takes a single format without converting refuses it with not-negotiated from the source.

Why only sometimes, and only on Linux CI: on GStreamer 1.24 (CI runs 1.24.2), a live aggregator waits on the clock before PLAYING, while its base time is still 0. Its first deadline has therefore already passed, and it can negotiate before its inputs have caps. GStreamer 1.26 gates this ("live but not PLAYING yet"). In a real flow the bus negotiates blind on any GStreamer version whenever an input joins after the flow has started.

Change

A caps-query probe on capssetter_out_O's sink pad answers with what downstream of the setter accepts, with the stamped channel-mask opened again. It fires per query, not per buffer, and holds no reference to the element. The mixer fixes its output from the first entry of that answer and also hands the answer to its own input pads, so the answer is ordered:

1. Downstream's caps with downstream's rates, so a blind pick lands on a rate a consumer without a resampler takes.
2. The same caps with any rate, so a rate locked by a mixer further downstream does not restrict the router's inputs. Once an input has caps, the mixer still pins its other inputs to that rate, as before; inputs at mixed rates need their own resampler.
3. Within each, F32LE/F64LE first when downstream accepts float. A converting consumer lists its own output format first; without this the bus would sum in that format (S16LE, say) and saturate on fan-in.

Behaviour changes, with the fader and soft clipper off (they already pin F32LE):

• A consumer that pins a format or a rate now gets it instead of not-negotiated. A bus that negotiates before any input picks the consumer's rate (48 kHz for a 48 kHz consumer) instead of 44.1 kHz.
• A consumer that converts but accepts float now gets a float bus, whatever the input format. Before, the bus took the first input's format.

Tests

All build the block through its builder.

test	block reverted, or the named part removed	this PR
an_input_that_joins_after_the_bus_started_reaches_{a_float,an_integer}_consumer: bus negotiates with nothing connected, then an input joins	not-negotiated (probe removed)	pass
a_late_input_reaches_a_mixer_that_locked_its_rate_on_the_router: router → audiomixer locked at 44.1 kHz, then a 48 kHz input joins	not-linked (rate kept in the answer)	pass
a_late_input_reaches_a_consumer_that_converts_format_but_not_rate: audioconvert then a 48 kHz-only consumer	not-negotiated (rate dropped from the answer)	pass
a_consumer_that_converts_to_integer_{leaves_a_float_bus_in_float,gets_a_float_bus_from_an_integer_input}: audioconvert ! S16LE consumer	bus S16LE (float-first removed)	bus F32LE

Each revert was run on macOS (GStreamer 1.28.6). On the rig (GStreamer 1.24.2), the rest of the file over 30 interleaved runs per arm: base block and harness 15/30 runs fail, this PR 0/30. The full file including the new tests: 10/10 pass.

The rig is ubuntu:24.04 with the ci.yml package list, run with --cpus=4. It is arm64; CI is x86_64.

Test harness: audiointerleave

The one multi-channel test also failed on its own plumbing, about 1 in 55 rig runs with the block fixed: audiointerleave0 "not negotiated". The harness's audiointerleave is a live aggregator. When its first deadline passes after the sources have answered the latency query but before their caps reach it, it aggregates anyway, cannot build an output format, and errors.

start-time-selection=first makes it wait for the first input buffer, which always follows the caps. To make the window deterministic, a scratch build held the caps event on the interleaver's sink pads for 300 ms (one binary, the property switched by an env var, arms interleaved):

caps held, 20 pairs	default	first
rig, GStreamer 1.24.2	19/20 fail, all "not negotiated"	0/20
macOS, GStreamer 1.28.6 (aggregator logging on)	20/20 fail	0/20

Unheld, CPU load did not raise the base rate (8 full-file pairs at --cpus=2 plus 4 busy loops: 0 failures either arm). The held-caps build is scratch only: no committed test guards this setting, because the window cannot be opened from the test without the scratch hook.

Not addressed here: under taskpolicy -b on a loaded Mac, both arms sometimes read silence: sources starved past the bus's 30 ms aggregation deadline. The reverted block also produced 44 not-negotiated errors in 12 runs; this PR produced none. The silence failures never occurred in the rig.

Ran: cargo test --test liveaudiorouter_test (counts above; 34/34 on macOS), cargo test --workspace on macOS (995 passed, 0 failed, 2 ignored), cargo fmt --all, cargo clippy --all-targets -- -D warnings.

🤖 Generated with Claude Code

[srperens]

Verdict: Approve — the cause is in the block, the probe is per-query with no captured reference, and the six new tests run in CI through the real builder.

Claims

Claim	Verdict	Evidence
The probe fires per query, not per buffer, and holds no reference to the element	CONFIRMED	see Diagnosis
The tests go through the block, not a rebuilt topology	CONFIRMED	backend/tests/liveaudiorouter_test.rs:264 — let result = liveaudiorouter::LiveAudioRouterBuilder
The new tests executed in CI	CONFIRMED	Check (Linux) job 108551289114 at 7d726d0: all six new tests ok, liveaudiorouter_test 34 passed
capssetter answers a caps query with the filter or ANY, and audiomixer then picks S32LE/44.1 kHz	EXTERNAL	upstream behaviour; assumed, and consistent with the reverted arms failing as the body's table says

Diagnosis — Right layer. The probe is a query probe that captures nothing, and it takes the setter from pad.parent_element() on each call:

backend/src/blocks/builtin/liveaudiorouter.rs:736 — sink.add_probe(gst::PadProbeType::QUERY_DOWNSTREAM, |pad, info| {

The answer is built from what the consumer really takes: backend/src/blocks/builtin/liveaudiorouter.rs:754 — let mut accepted = src. The stamped channel-mask is removed again, so caps_out_O's unpositioned mask still intersects. Coverage is BOUNDED to the output bus. A second input at another rate, when neither input resamples, is still refused. That is not this PR's cause: #886 tracks it, found while reviewing this one.

The ordering is the non-obvious part. Downstream rates come first so a blind pick lands on one the consumer takes. The same caps at any rate come second, so a rate a downstream mixer has locked does not refuse a later input.

Behaviour change worth knowing before merge. With fader and clipper off, a consumer that accepts float now gets an F32LE bus even when every input is integer. It used to get the first input's format. It matches the F32LE pin #795 (f63d5e9) added on the fader path, and it removes fixed-point saturation on fan-in. A consumer that takes only an integer format still gets it (...an_integer_consumer).

Radius — LOCAL: one element's probe in one block. Every builtin.liveaudiorouter output bus gets it, and no other block calls make_capssetter.

Overlaps — none owns this decision. #886 is the follow-up on the input side. #785 (Option D, decided) will edit the same test file: textual only.

Tests & CI — every check green at 7d726d0. macOS/Windows skipped; nothing platform-specific. The flake-rate numbers (15/30 → 0/30) come from the author's rig and cannot be re-measured here. They do not affect the verdict: the late-input tests prove the mechanism deterministically. The same flake stopped Check (Linux) on #879 today (job 108488781339, a_routing_change_moves_audio_between_output_channels_while_playing, not-negotiated). Merging this should let those reruns go green.

Confidence: HIGH