The Hybrid Panel That Heard Its Own Echo Three Words Late: Building a Mix-Minus Bus for Room-to-Platform Audio
When a hybrid panel reports that platform participants are hearing the room feed delayed by a few words, the instinct is to reach for echo cancellation. That instinct is usually wrong. The symptom class — a room hearing itself through the platform return — is a routing diagnosis before it is a DSP diagnosis. If the platform return is present in the room PA bus or the program bus, no amount of AEC tuning will remove the self-return cleanly. The fix is a mix-minus bus per outbound destination, verified before doors open.
This article is a diagnostic pattern, not a reported incident. It assumes a competent A1 or streaming engineer who needs a reversible, testable procedure. Every claim below is either sourced from primary documentation or framed as a recommendation.
What mix-minus actually does
Mix-minus is a method of creating a separate audio mix that excludes one or more audio sources to prevent feedback loops and echoes (vMix Knowledge Base). The primary reason to design a mix-minus system is to prevent feedback in conferencing or sound reinforcement applications (Biamp). In a sound reinforcement scenario, the mix of audio playing from the loudspeaker closest to the presenter should not include the presenter’s own speech (Biamp).
The same logic applies to the platform side. Sending a master mix to remote guests can cause an echo because that master mix may contain the remote guest’s own audio; a mix-minus avoids sending the guest their own audio (vMix). In a hybrid panel, the “remote guest” is the platform return itself — the room’s own audio coming back through the platform. If that return is routed into the room PA or the program bus, the room hears itself.
The three outbound buses every hybrid panel needs
A single “master minus one” is insufficient for a hybrid panel with multiple acoustic and digital paths. Build the matrix per destination, not per source. Each destination needs its own exclusion list.
1. Room PA bus
Feeds the in-room loudspeakers. It must exclude every room microphone that the PA loudspeakers can acoustically reach. It must also exclude the platform return if the platform return is being amplified into the room — otherwise the room hears the platform’s version of itself. Biamp notes that the loudspeaker closest to the presenter should not carry the presenter’s own speech; extend that rule to the platform return.
2. Platform/program bus
Feeds the platform encoder. It must exclude the platform return. This is the bus where the “three words late” symptom usually originates: the platform return is mixed back into the program feed, so the platform receives its own delayed audio. The platform then sends that delayed audio back to the room, and the room hears itself a few words late.
3. Remote-guest or call-in bus
Feeds any remote guest, call-in, or second platform endpoint. It must exclude that guest’s own audio. vMix documents this directly: sending the master mix to remote guests causes echo because the master contains the guest’s audio; mix-minus avoids it.
Lectrosonics describes a multi-site bridging setup that requires a minimum of four mixes: an AEC signal mix, send mixes including the AEC output, and local mixes (SPNCWB Technical Data). That count is for a specific bridging product, but the principle generalizes: each outbound destination gets its own mix, and the AEC reference is a separate mix from the send mixes.
Diagnostic sequence for the “three words late” symptom
Work in this order. Each step is reversible and testable before doors open.
Step 1: Classify the echo path
Is the echo acoustic (speaker-to-mic) or digital (platform return re-entering the program bus)? The distinction matters because the fixes are different. An acoustic echo is a room problem; a digital echo is a routing problem. If the platform return is present in the program bus, the platform will receive its own delayed audio regardless of room acoustics.
Step 2: Check the operator position
If the operator is monitoring on speakers or loud headphones, the operator’s microphone can pick up the platform return and feed it back into the program bus even when the digital mix-minus is correct. vMix documents this: if a guest is still hearing an echo, it may come from the operator using speakers or loud headphones, or from the guest using speakers or loud headphones so their own microphone picks up the production audio. The fix is headphones only at the operator position, and a check that no camera or ambient mic is open and picking up the room.
Step 3: Trace the platform return
Follow the platform return from the decoder to every bus it touches. It should appear only in the room PA bus (if the room needs to hear the platform) and in the remote-guest bus (if a remote guest needs to hear the platform). It must not appear in the program bus. If it does, that is the routing error.
Step 4: Verify gain structure
Biamp describes improperly configured gain structure as the number one killer of mix-minus and acoustic echo cancellation. Before touching AEC, confirm that each microphone’s input gain is set so that a typical talker at a typical distance produces a similar level across all mics. Biamp’s starting point: the average level for a talker in a quiet room is 65 dB when measured from the talker to the microphone at a distance of 2.5 feet. That is a design reference, not a universal target; use it to check consistency, not to set absolute levels.
Step 5: Synchronize AEC reference with the PA feed
If the design includes AEC, Biamp notes that level changes made to the sound reinforcement feed need to be reflected to the AEC reference. If the PA level changes and the AEC reference does not, the AEC is canceling the wrong signal. This is a common source of residual echo that looks like a routing problem but is actually a reference-tracking problem.
What RTP/RTCP can and cannot tell you
RTP provides end-to-end network transport functions for real-time data such as audio, but it does not guarantee quality-of-service or timely delivery (RFC 3550). RTP sequence numbers allow the receiver to reconstruct the sender’s packet sequence, but RTP does not guarantee delivery or prevent out-of-order delivery (RFC 3550). RTCP is used to monitor quality of service and convey information about participants in an ongoing session (RFC 3550).
These are observability tools, not root-cause proof. RTCP reception reports and RTP sequence numbers can tell you about loss and timing reconstruction. They cannot tell you that a specific bus was mis-routed. Keep the two diagnostic tracks separate: use RTP/RTCP to rule out network loss and jitter, then use the bus matrix to rule out routing.
Audio-level metadata as a routing aid, not a substitute
RFC 6464 defines an RTP header extension that lets audio packets indicate the audio level of the sample carried in the packet (RFC 6464). If the platform supports the ssrc-audio-level extension, you can see which streams are active without decoding every stream. That is useful for confirming that a source is present on a bus.
But RFC 6464 is explicit that mixers and forwarders generally ought not base audio forwarding decisions directly on packet-by-packet audio level information, but rather ought to apply some analysis of the audio levels and trends. Use the level metadata to confirm activity, not to make routing decisions. A stream showing activity on the program bus does not tell you whether that stream should be there; the bus matrix does.
The reversible fix order
If the echo persists after the mix-minus matrix is verified, work in this order. Each step is reversible.
- Verify the exclusion matrix. Solo each outbound bus and confirm that no bus contains its own destination’s source. This is the first check, not the last.
- Bypass the platform return from the room PA. If the room does not need to hear the platform return, remove it from the PA bus entirely. This eliminates the acoustic path from the PA loudspeakers back into the room mics.
- Re-introduce one path at a time. Add the platform return back to the PA bus, then to the remote-guest bus, testing after each addition. If the echo returns, you have found the path.
- Only then touch AEC or codec settings. If the routing is clean and the echo persists, the problem is in the AEC reference or the codec’s own mix. Change one setting at a time and document the change.
Lectrosonics notes that when a local sound system amplifies local microphones as well as far-side audio, far-side audio re-circulates through the local sound system, making it more difficult for the AEC to identify and cancel. That is the acoustic version of the same problem: the room is reinforcing a signal that contains its own delayed return. The mix-minus bus is the structural fix; AEC is the cleanup.
Copyable artifact: Hybrid Panel Mix-Minus Bus Checklist
For the A1/streaming engineer. Print this, fill it in during load-in, and keep it at the console.
HYBRID PANEL MIX-MINUS BUS CHECKLIST
Role: A1 / Streaming Engineer
Event: ______________________ Date: __________
1. SOURCE INVENTORY
[ ] Room mic 1: ______________ Bus(es): ______________
[ ] Room mic 2: ______________ Bus(es): ______________
[ ] Room mic 3: ______________ Bus(es): ______________
[ ] Platform return: __________ Bus(es): ______________
[ ] Remote guest: _____________ Bus(es): ______________
[ ] Program playback: _________ Bus(es): ______________
2. DESTINATION MATRIX (mark X where source is INCLUDED)
Source \ Destination | Room PA | Program | Remote Guest
----------------------|---------|---------|-------------
Room mic 1 | | |
Room mic 2 | | |
Room mic 3 | | |
Platform return | | X | X
Remote guest | | X |
Program playback | | X | X
RULE: Platform return must NOT appear in Program bus.
RULE: Each destination must exclude its own source.
3. EXCLUSION RULES
[ ] Room PA excludes every room mic the PA can reach.
[ ] Room PA excludes platform return if PA amplifies it.
[ ] Program bus excludes platform return.
[ ] Remote-guest bus excludes that guest's own audio.
4. OPERATOR HEADPHONE CHECK
[ ] Operator is on headphones only.
[ ] No camera or ambient mic is open and picking up the room.
[ ] No speaker is feeding the operator mic.
5. VERIFICATION LOOP
[ ] Solo Room PA bus: confirm no room mic is present.
[ ] Solo Program bus: confirm platform return is absent.
[ ] Solo Remote-guest bus: confirm guest's own audio is absent.
[ ] Send a test signal from the platform; confirm it does not
return to the platform via the program bus.
[ ] Confirm AEC reference tracks the PA feed level.
6. REVERSIBLE FIX ORDER (if echo persists)
[ ] 1. Verify exclusion matrix.
[ ] 2. Bypass platform return from room PA.
[ ] 3. Re-introduce one path at a time.
[ ] 4. Only then touch AEC or codec settings.
Signed: ______________________ Time: __________
What this checklist does not do
It does not measure latency. The “three words late” symptom is a description, not a measurement. If you need to quantify the delay, measure it at the platform return with a timestamped test signal, not by counting words. The sources cited here do not provide a conversion from words to milliseconds, and this article does not invent one.
It also does not replace the platform’s own documentation. Platform-specific routing and mix-minus support vary. Confirm with the platform vendor whether the return can be excluded per destination before assuming the matrix above maps directly to the platform’s UI.
FAQ
Why does the echo sound like it is three words late rather than immediate?
The delay is the round trip through the platform: room mic to encoder, encoder to platform, platform back to decoder, decoder to room PA. The exact delay depends on the platform’s encode, network, and decode times. The “three words” description is a perceptual marker, not a measurement. The routing error is the same regardless of the delay length.
Can AEC fix this without a mix-minus bus?
No. AEC cancels acoustic echo between a loudspeaker and a microphone. It does not remove a digital return that is mixed into the program bus. If the platform return is in the program bus, the platform receives its own audio before AEC ever sees it. Fix the routing first.
What if the room needs to hear the platform return?
Then the platform return belongs in the room PA bus, but not in the program bus. The room PA bus can include the platform return as long as the room mics that feed the program bus are excluded from the PA bus, or as long as the PA level is low enough that the room mics do not pick it up. Biamp’s guidance on gain structure and AEC reference tracking applies here.
How do I know the mix-minus is working before doors open?
Solo each outbound bus and confirm that no bus contains its own destination’s source. Then send a test signal from the platform and confirm it does not return to the platform via the program bus. This is the verification loop in the checklist. It takes less than five minutes and catches the routing error before the audience arrives.
Does RFC 6464 audio-level metadata help find the routing error?
It helps confirm which streams are active on a bus. It does not tell you whether a stream should be on that bus. Use it as a routing aid, not as a substitute for the bus matrix. RFC 6464 itself warns against basing forwarding decisions on packet-by-packet levels.
Related reading
For the handoff between the room and the platform chat, see Why Hybrid Events Fall Apart at the Room-to-Chat Handoff. That article covers the adjacent failure mode where the chat and the room audio diverge; this one covers the audio bus that keeps the room from hearing itself.