Audio for Live Broadcast

May 31, 2026 27 min read Audio Engineering

live-productionaudiobroadcastingstreamingchurch-techmixing

Contents

This is the third post in a series on broadcasting meetings and church services. The first post laid out the signal-flow mental model — how a live signal is born at a source, moves through a chain of devices, and arrives at a viewer — and the second covered cameras and the switcher that ties them together: PTZOptics PTZ cameras feeding a Blackmagic ATEM. Both of those posts were, in a sense, about the part of the broadcast that people see. This one is about the part they hear, and it is the part almost everybody gets wrong.

Here is the uncomfortable truth that took me years and several embarrassing live failures to internalize: viewers will forgive astonishingly bad video, and they will not forgive bad audio. You can stream a slightly soft, slightly noisy, slightly poorly framed 720p image of a speaker and people will watch the whole thing. Make that same speaker hard to understand — muffled, echoey, swimming in room noise, clipping on every loud word, or just plain too quiet — and they are gone in under a minute. They will not consciously think “the audio is bad.” They will think “this is hard to follow” or “this feels amateur” and they will close the tab. Audio is the channel through which the actual content of a meeting or a service travels. The video is decoration. If you have a fixed budget of time and attention, spend it on audio first, and it is not close.

This post stands on its own. You do not need to have read the first two, though it helps. What you do need is a sound board — an audio mixing console of some kind — and a video encoder or switcher that the stream comes out of. Everything here is about the wire that runs between those two things, and the decisions that determine whether the audio on that wire is broadcast-grade or garbage.

Why Audio Is the Part Everyone Gets Wrong

There is a structural reason audio gets neglected, and it is worth naming because once you see it you can defend against it. Video is visible during setup. You point a camera, you look at a monitor, and you can immediately see whether the shot is good. The feedback loop is instant and obvious, so people pour attention into it. Audio is invisible. The waveform on a screen does not tell you whether the speech is intelligible; you have to actually listen, on the actual playback device, with the actual room noise, and most people testing a broadcast do none of those things. They glance at a meter, see it bouncing, and declare victory. Then the service starts and the audio is a disaster, and nobody on the team can say exactly why, because nobody was really listening.

The second reason is that audio for broadcast is genuinely a different job from audio for the room, and the person running the sound board is, correctly, focused on the room. Their entire attention is on the congregation or the audience physically present — making sure the speaker is loud enough to be heard in the back row, making sure the music sounds full in the space. The stream is an afterthought, often handled by feeding the broadcast whatever happens to be coming out of the main speakers. That single decision — “just send the stream the main mix” — is the root cause of a huge fraction of bad broadcast audio, and we will spend a lot of this post unpacking why.

The third reason is that audio problems are sneaky. A loose video cable produces a black screen: catastrophic, but obvious and fixable. An audio problem is usually not catastrophic; it is a slow degradation. A little too much room reverb. A speaker who turned their head away from the lav. A guitar that is loud in the room but inaudible on the stream. Background HVAC hum. Each one individually is survivable. Together they add up to a broadcast that is exhausting to listen to, and because no single thing is obviously broken, nobody fixes any of it.

The good news is that fixing broadcast audio is mostly a matter of a few correct decisions made once, at install time, rather than heroics every week. Get the source right, get the mix right, get the levels right, and the system runs itself.

Rule One: Take a Clean Feed Off the Board, Never a Room Mic

The single most important decision in broadcast audio is where you get the audio from. There is exactly one right answer and it is: a dedicated electrical send off the sound board. Not a microphone pointed at the room. Not the camera’s onboard mic. Not a mic taped to a speaker cabinet. A wire, carrying a line-level mix, coming out of a dedicated output on the console.

Why does this matter so much? A microphone in the room captures everything: the speaker, yes, but also the room’s reverberation, the HVAC, chairs creaking, the person two rows back unwrapping a cough drop, the PA speakers themselves (which creates a hollow, distant, “recorded in a gymnasium” sound), and — critically — the acoustic reflections that make speech hard to understand. A clean feed off the board captures only the signals that are plugged into the board: the speaker’s lav, the pulpit mic, the instruments, each one a close, dry, intelligible source. The difference between a room-mic stream and a board-feed stream is the difference between “I am listening to a recording of a room” and “I am listening to the speaker.”

If you take nothing else from this entire post, take this: get your broadcast audio from a dedicated output on the sound console, and run it as a wire to your encoder or switcher. Everything else is refinement on top of that one decision.

Now, which output off the board? Consoles have several kinds of outputs, and they are not interchangeable for this purpose. Here is the landscape:

Output type	What it is	Good for broadcast?
Main L/R (Main Mix)	The primary mix sent to the house PA	Works, but it is the house mix — see the next section
Aux send (Auxiliary)	A separate mix, traditionally for monitors or effects	Excellent — a fully independent broadcast mix
Matrix out	A mix-of-mixes, sums other outputs in chosen proportions	Excellent — purpose-built for alternate feeds
Group / Sub-group	A bus that sums a subset of channels	Usable, but coarse; less independent control
Direct out (single channel)	One channel’s signal, pre- or post-fader	Only for single-source feeds, not a full mix
Record / USB / Stream out	A dedicated output some digital consoles provide	Often the easiest right answer if present

For a serious install, you want either an aux send configured as a stereo (or mono) broadcast mix, or a matrix output. Both give you a mix that is independent of the main house mix. On a digital console — a Behringer X32, a Midas M32, an Allen & Heath SQ or Avantis, a Yamaha QL or TF — you simply assign a matrix or an aux bus to be your “Broadcast” mix, name it that, and route it to a physical output (analog XLR, or better, a digital format we will get to). On an older analog console you use a spare pair of aux sends, or a matrix section if the board has one. Many modern digital consoles even label a dedicated “USB record” or “stream” output, which is fine to use as long as you understand that it is just another bus.

The reason independence matters is the subject of the next section, and it is the second-biggest idea in this entire post.

The Broadcast Mix Versus the House Mix

Here is the problem that the “just send the main mix” approach runs into, and it is not a small one. What sounds right in the room and what sounds right on the stream are two different mixes, because the room is doing half the work for the house and none of the work for the stream.

Consider an acoustic instrument — say a drummer playing an acoustic kit, or a piano, or an acoustic guitar, or even a strong singer who projects well. In the room, that instrument is physically loud all by itself. The sound engineer barely puts any of it through the PA, because it does not need help; the room already hears it. The PA fills in the gaps — vocals that cannot compete, a bass guitar that has no acoustic volume of its own, a kick drum that needs reinforcement. The house mix is therefore not the full music. It is the difference between what the room produces acoustically and what the audience needs to hear. The PA mix is a supplement.

Now feed that house mix to the stream. The viewer at home does not have the room. They do not hear the acoustic drum kit, the projecting singer, the piano in the air. They hear only the supplement — the few things the engineer pushed through the PA. The result is a stream where the kick drum and a couple of vocals are present and the entire rest of the band is a faint ghost. Acoustic instruments that dominated the room are nearly silent on the stream. The mix sounds gutted, hollow, wrong — and the engineer in the room cannot hear the problem, because in the room it sounds great.

This is why a dedicated broadcast mix is not a luxury, it is a requirement for any room where significant sound is produced acoustically. On a broadcast aux or matrix, you mix for the home listener, who has no room: you bring up the acoustic instruments that the house barely needs, you set the vocal-to-music balance that works on headphones and phone speakers, and you do it independently of whatever the FOH engineer is doing for the audience.

The same logic applies in the other direction. Speech-heavy meetings often have the opposite issue: a podium mic that is plenty loud in a small room (so FOH keeps it low) but that needs to be the dominant, forward, present voice on a stream. And the broadcast mix needs things the house mix actively does not want: for instance, you may want a touch of crowd or ambient mic in the broadcast for energy, while FOH would never put crowd mics through the PA (instant feedback). A separate broadcast mix lets you make these choices on purpose.

                THE TWO-MIX PROBLEM, ILLUSTRATED
                ================================

  ACOUSTIC SOURCES IN THE ROOM          WHAT EACH MIX NEEDS
  ----------------------------          -------------------

  Drum kit  (LOUD acoustically) ----->  HOUSE MIX:  barely any kick only
  Piano     (LOUD acoustically) ----->  (room supplies the rest)
  Projecting singer (LOUD)      ----->
  Quiet vocalist (needs PA)     ----->  vocal + bass + kick   = SUPPLEMENT
  Bass guitar (no acoustic vol) ----->

                                        BROADCAST MIX:  ALL of it,
                                        balanced for a listener
                                        who has NO room
                                        drums + piano + ALL vocals +
                                        bass, mixed for headphones

   If the stream gets the HOUSE MIX, the home viewer hears only the
   "supplement" and the music sounds hollow and gutted.

The practical upshot: budget a few minutes of someone’s attention, every event, to listening to the broadcast mix on headphones or a small monitor — not the room. Ideally a different person from the FOH engineer, because the two jobs pull in different directions. In a tiny operation where one person does both, at minimum solo the broadcast bus into headphones during soundcheck and ask “would I want to listen to this if I were at home?”

Getting Audio Into the Video: Embedding Versus a Separate Path

Once you have a clean broadcast mix coming off the console, you have to get it to the encoder. There are two architectures, and the right one depends on your switcher and your encoder.

Option A: Embed audio into the SDI/HDMI signal at the switcher. Digital video interfaces can carry audio inside the video signal. SDI in particular was designed for this: the audio rides in the horizontal blanking interval of the video stream, the slice of the signal that carries no picture. The relevant standards are SMPTE 272M for standard-definition SDI and SMPTE 299M for HD/3G-SDI; the HD/3G variant carries up to 16 channels of 24-bit, 48 kHz audio, organized into audio groups of four channels each. HDMI carries embedded audio too. The point of embedding is that once the audio is inside the video, the two travel together as a single cable, a single stream, perfectly locked in time. There is no separate audio wire to forget, mislabel, or get out of sync.

Option B: Feed a separate audio path straight into the encoder. Many software encoders (OBS, vMix) and hardware encoders accept an audio input directly — a USB audio interface, an analog input, or a separate digital feed — independent of the video. The video comes in one way, the audio another, and the encoder marries them. This is simpler to wire when your switcher does not handle audio well, and it gives the encoder operator independent control of audio level. The cost is that you now own the sync problem yourself (next section), because the audio and video took different paths with different delays.

For most installs built around a Blackmagic ATEM, Option A — embedding at the switcher — is the cleaner architecture, because the ATEM is genuinely good at audio. Every ATEM has a built-in Fairlight audio mixer. The switcher automatically de-embeds the audio from every SDI input and presents each as a channel in the Fairlight mixer, and the models also have analog audio inputs (typically a pair of 3.5 mm or XLR/TRS inputs depending on model) and, on larger units, dedicated mic inputs. So you bring your console’s broadcast mix into the ATEM — either as embedded audio on an SDI feed, or via the analog inputs — and the Fairlight mixer handles it. Fairlight gives you, per channel, a six-band parametric EQ, a compressor, a limiter, a gate/expander, and level control, plus a master bus with its own dynamics. The ATEM then re-embeds the final audio mix into its PROGRAM output, and that single SDI cable goes to your encoder carrying perfectly synced video and audio together.

A word on the ATEM’s “audio follows video” (AFV) feature, because it is a trap for broadcast. AFV makes an audio source automatically fade up when its video input is on PROGRAM and fade down when it is cut away. That is wonderful for a multi-source production where each camera has its own local audio. It is exactly wrong for a meeting or service, where your audio comes from the sound board and must stay constant regardless of which camera is live. For our use case you want your broadcast-mix channel set to “ON” permanently (not AFV), so the audio is rock-steady while the video cuts between cameras. Set the camera SDI channels to AFV-off or simply un-route them, and keep one always-on channel: the console feed.

Here is the trade-off table:

Consideration	Embed at switcher (ATEM/Fairlight)	Separate path into encoder
Sync	Locked by design; video+audio in one stream	You must align it manually
Cabling	One cable from switcher to encoder	Separate audio cable to encoder
Audio processing	Fairlight EQ/comp/limiter on the switcher	Encoder software (OBS/vMix) or none
Operator control	At the switcher	At the encoder
Best when	Switcher has good audio (ATEM does)	Switcher audio is weak or absent
Failure mode	One cable carries everything (single point)	Two things to keep working and in sync

Audio-to-Video Sync: The Delay Nobody Budgets For

Even with embedded audio, sync is a real problem, and it comes from a direction people do not expect. The culprit is video processing delay. Every device that touches the video — the switcher, a scaler, a frame synchronizer, the encoder, the streaming platform’s own pipeline — takes some amount of time to do its work, and that work delays the video by a handful of frames. Audio, by contrast, is comparatively cheap to process and gets through the chain faster. The net result is that, untreated, the audio arrives ahead of the video: the viewer hears the word slightly before they see the mouth move. Because the video is what got delayed, the fix is to delay the audio to match.

This is counterintuitive for people who come from a “the audio is late, I need to push it earlier” mental model. In a broadcast chain it is almost always the reverse. The video falls behind because of processing, and you add a delay to the audio so the two line up. The amount is usually small — on the order of a few frames, which at 30 fps is tens of milliseconds, occasionally up to a couple hundred milliseconds in a chain with heavy scaling or a frame sync in the path. Lip-sync errors become noticeable to most viewers somewhere around 45 milliseconds of audio-leads-video, so this is well within the range that matters.

How do you actually fix it? The clean answer is an audio delay applied to the broadcast feed, after the console but before (or at) the point where audio and video marry. On an ATEM, the Fairlight mixer has a per-input and master audio delay you can dial in. On a digital console, the broadcast bus can carry an output delay. Standalone audio delay units exist too. The procedure is empirical and you do it once at install: stream a test, point a camera at someone clapping or at a video with a clap or a clear plosive sound, watch the stream on the actual platform (with its full pipeline delay), and nudge the audio delay up until the clap you hear matches the clap you see. Write the number down. It will not change unless you change the video chain.

A few honest caveats. First, the platform adds its own latency that you cannot control, but platform latency generally delays audio and video together, so it does not by itself create a sync offset — your job is only the relative offset introduced inside your own chain. Second, if you ever add a device to the video path (a new scaler, a different switcher mode), re-check sync; the number can move. Third, beware feeding audio to the encoder by a separate path from the video (Option B above): now the two never shared a clock, and you are aligning two independently-buffered streams, which is fiddlier than aligning embedded audio. This is the strongest practical argument for embedding.

Loudness for Streaming: Targets, True Peak, and Platform Normalization

Now the question of how loud. This is where a lot of otherwise careful operators fall down, because the streaming world measures loudness differently from how a sound board’s meters work, and the platforms quietly change your levels after you upload.

The modern unit is LUFS — Loudness Units relative to Full Scale — a measurement designed to track perceived loudness over time, not just instantaneous peak level. The “integrated” LUFS figure is the loudness averaged across the whole program. This is what platforms normalize against. The key fact: every major streaming platform applies loudness normalization. YouTube, for instance, turns down content that is louder than its internal target and leaves quieter content alone (it generally does not turn quiet content up). YouTube’s normalization target sits around -14 LUFS. So if you upload a stream blasting at -9 LUFS, YouTube turns it down to roughly -14 and any aggressive compression you applied to get loud was wasted — worse, it audibly squashed your dynamics for nothing.

There is a spread of conventions here, and it is worth knowing the landscape so you can make a deliberate choice:

Context	Integrated loudness target	True-peak ceiling
EBU R128 (European broadcast)	-23 LUFS (±0.5 LU)	-1 dBTP
ATSC A/85 (US broadcast)	-24 LKFS	-2 dBTP
Podcast / spoken-word convention	-16 LUFS (mono often -19)	-1 dBTP
Music streaming (Spotify, etc.)	~-14 LUFS	-1 dBTP
YouTube normalization	~-14 LUFS	-1 to -2 dBTP

For a live broadcast of a meeting or service — which is mostly speech with some music — a sensible, defensible target is around -16 LUFS integrated for a stereo stream, with a true-peak ceiling around -1 dBTP. This sits in the comfortable middle: loud enough to feel present on phone speakers and earbuds, not so loud that platform normalization claws it back and undoes your dynamics, and with enough headroom that the encoder’s lossy codec does not push intersample peaks into clipping. If your content is predominantly music you might drift toward -14; if it is pure spoken word you can sit at -16 to -18 and let the platform normalization bring it up to match everything else.

Two terms deserve a clear distinction. Peak (or sample peak) is the highest value any individual audio sample reaches. True peak (dBTP) accounts for the fact that when a digital signal is reconstructed into an analog waveform — and when it is re-encoded by a lossy codec like AAC, which the platforms use — the actual waveform can overshoot the highest sample, producing intersample peaks that clip even though no single sample hit 0 dBFS. That is why the ceiling is -1 dBTP and not 0: you leave a dB of headroom so the codec does not produce audible clipping on the loudest transients. A true-peak limiter on your broadcast master bus enforces this. The ATEM’s Fairlight master has a limiter; digital consoles have one on the output bus; software encoders can apply one too.

The practical workflow: put a loudness meter somewhere you can see it on the broadcast feed. Many digital consoles have an LUFS meter built in; OBS and vMix have loudness metering or plugins; standalone meters and free software meters exist. During a typical segment, watch the integrated (long-term) reading and adjust your broadcast master so it settles around your target. Set a true-peak limiter at -1 dBTP and a gentle bus compressor to keep the dynamic range under control without squashing it. Then listen — on a phone speaker, which is how most people will hear it. Do not chase the meter at the expense of intelligibility. The meter is a guide; the ear is the judge.

Microphones: Choosing for Speech and for Music

Microphone choice is where the chain begins, and a bad choice here cannot be rescued downstream. For broadcast, the governing principle is isolation: you want each mic to capture its intended source and as little of everything else as possible, because everything else is room, reflection, and noise that muddies the stream.

For speakers — the person talking, preaching, presenting — you have three main families:

Mic type	How it is worn/placed	Strengths	Weaknesses
Lavalier (lapel)	Clipped to clothing, ~8 in. from mouth	Invisible, hands-free, mobile	Distance varies as head turns; rustle from clothing; lower gain-before-feedback
Headset (head-worn)	Boom arm holds capsule near corner of mouth	Constant mouth distance = consistent, intelligible, high gain-before-feedback	Visible on camera; setup fuss; can pick up plosives if mispositioned
Podium / gooseneck	Fixed mic on a stand or lectern	Robust, no battery-on-presenter, no wearing	Only works when the speaker stays at the podium; reach is limited

For broadcast specifically, a headset mic is usually the best speech result because the capsule stays a fixed, close distance from the mouth no matter how the speaker moves their head — which means consistent level and the best intelligibility, the thing that matters most on a stream. Lavaliers are more discreet and very common, but the level dips every time the speaker turns their head away from the lav, and that inconsistency is audible. Gooseneck podium mics are excellent for a fixed lectern but useless the moment the presenter walks. Many rooms use a combination: gooseneck at the podium, plus a couple of wireless lavs or a headset for roaming presenters.

For music, you are in the world of dedicated instrument and vocal mics, and the broadcast benefit of close-miking is the same as everywhere: a close mic on a guitar amp, a piano, or a vocalist captures a dry, isolated source that you can place in the broadcast mix on purpose. This is precisely the audio that the house mix often under-uses (because the instrument is loud acoustically) and that the broadcast mix desperately needs (because the home listener has no room). The mics themselves are the FOH engineer’s domain; your job on the broadcast side is to make sure those channels are available to your broadcast bus and bring them up to a balance that works for a listener with no room.

A note on wireless: every wireless lav or headset is a potential failure and noise source. Use good systems, manage your RF, keep fresh batteries, and always have the speech mic well-isolated, because a dropout or a burst of RF hash on your only speech mic is a broadcast killer.

Feedback and Room Reflections

Two enemies haunt live audio, and both are worse for broadcast than people assume.

Feedback is the howl or ring that happens when a microphone picks up the sound of the PA speakers reproducing that same microphone, forming a loop that builds until it screams. It is fundamentally a problem of the room — mic too close to a speaker, gain too high, a resonant frequency the room loves. The relevant point for broadcast is that your broadcast feed is taken off the board before it hits the room’s PA, so a clean board feed is largely immune to room feedback — another reason the board feed beats a room mic, which would capture every squeal. Your job is mostly not to create new feedback paths: do not route a broadcast monitor speaker back into a room mic, and if you put a “crowd” or “ambient” mic into the broadcast for energy, keep it out of the house PA entirely or it will feed back instantly. Tools the FOH engineer uses — a graphic EQ to notch out resonant frequencies, a feedback suppressor like the classic dbx units, careful mic and speaker placement — keep the room stable, which keeps your board feed clean.

Room reflections are subtler and, for broadcast, arguably more damaging than feedback because they are always present rather than occasional. Hard parallel surfaces — bare walls, a flat ceiling, a glass back wall — bounce sound around, and a microphone (especially a distant one) captures the original sound plus a smear of slightly-delayed copies. The result is the boxy, hollow, “speaking in a stairwell” quality that screams amateur on a stream. The first defense is, again, close miking and a board feed: a close mic captures mostly direct sound and little reflection, and the board feed never touches the room at all. Beyond that, the cure is acoustic treatment of the space — absorptive panels on the worst reflective surfaces — which is a building project beyond this post, but worth knowing as the real fix. On the broadcast bus you can shave a little with EQ (gently reducing boxy low-mids around 200-500 Hz often helps speech) and judicious high-pass filtering to cut rumble, but you cannot EQ your way out of a genuinely reverberant room. The mic technique and the board feed do the heavy lifting.

A Concrete End-to-End Broadcast Audio Chain

Let me make all of this concrete with a single example system, the kind I would actually install for a mid-sized room running a Behringer X32 or Allen & Heath SQ into a Blackmagic ATEM into an encoder. Walk the chain and you can adapt it to your gear.

            END-TO-END BROADCAST AUDIO CHAIN
            ================================

  SOURCES            CONSOLE                    SWITCHER (ATEM)        ENCODER     PLATFORM
  -------            -------                    ---------------        -------     --------

  Headset mic --+                              +------------------+
  Lav mics ---- +-->[ Input  ]                 | Fairlight mixer: |
  Podium gnk -- +   [ channels]                | - Broadcast chan |
  Inst./music - +   [ + EQ/   ]                |   set to ON      |   embedded
                    [ dynamics]                |   (NOT AFV)      |   SDI audio
                    [         ]                | - 6-band EQ      |  +video
                    [ MAIN MIX ]---> House PA   | - compressor     |
                    [ (room)   ]                | - LIMITER -1dBTP |--[Encoder]--RTMP-->[YouTube]
                    [          ]                | - AUDIO DELAY to |   (OBS /          [Facebook]
                    [ BROADCAST]---SDI or ----->| match video      |   vMix /          [your site]
                    [ AUX/MATRX]   analog into  | - master bus,    |   hardware)
                    [ (for home]   the ATEM     |   ~ -16 LUFS     |
                    [  listener)]               +------------------+
                                                         |
                                                         | re-embedded into
                                                         | PROGRAM SDI out
                                                         v
                                                  one cable: video + synced,
                                                  loudness-managed audio

Step by step:

Sources to console. Headset on the main speaker, a couple of wireless lavs for roaming presenters, a gooseneck at the podium, and whatever instrument and vocal mics the music needs. Each gets a channel on the X32/SQ with appropriate gain, a high-pass filter to kill rumble, and basic EQ and a gentle compressor for consistency.
Two independent mixes. The Main L/R feeds the house PA — the FOH engineer’s mix for the people in the room. A separate matrix or aux bus named “Broadcast” is the mix for the home listener: same sources, different balance, with the acoustic instruments brought up to compensate for the room the viewer does not have, and the speech pushed forward and present.
Broadcast bus into the ATEM. Route the Broadcast bus to a physical output and bring it into the ATEM — either embedded on an SDI feed or via the ATEM’s analog inputs. In the Fairlight mixer, set that channel to ON permanently, not AFV, so the audio is steady while video cuts between cameras.
Process on the master. On the Fairlight master bus, apply a gentle compressor to control dynamics, set a true-peak limiter at -1 dBTP, and watch a loudness meter to land the integrated loudness around -16 LUFS.
Sync. Dial in the audio delay (in Fairlight, or on the console’s broadcast output) so the audio lines up with the processing-delayed video. Verify on the actual platform with a clap test and write the number down.
One cable out. The ATEM re-embeds the finished audio into its PROGRAM SDI output. That single cable — video and perfectly synced, loudness-managed audio together — goes to the encoder, which streams it to YouTube, Facebook, or your own site.
Listen. Before you go live and during the event, monitor the broadcast feed on headphones and on a phone speaker. Not the room. Ask: would I want to listen to this from home? That question, asked honestly every single time, will catch more problems than any meter.

Closing: Boring, Repeatable, Intelligible

If this post has a thesis, it is the same discipline that runs through this whole series: build something boring and reliable rather than clever and fragile. For audio that means a clean dedicated send off the board, a broadcast mix made deliberately for a listener who has no room, audio embedded with the video so sync is locked, a delay tuned once and written down, and a loudness target you hit on purpose and verify by ear. None of it is glamorous. All of it is the difference between a stream people actually watch and a stream they close.

Spend your attention here first. The cameras and the switcher from the previous post are what people see, but the audio is what carries the content, and a viewer who cannot comfortably hear the speaker will never stay long enough to appreciate the shot. Get the audio right and you have done the hard, invisible, essential part of the job. In the next post we will move downstream to the encoder itself — encoding settings, bitrate, and the platforms — but it all rides on the foundation we built here: a clean, well-mixed, properly synced, loudness-managed feed coming off the board.