Multi-zone talk/listen and paging hub with mic-array AEC, multichannel A/V codec, internal Ethernet switching, PoE PSE ports, and time-stamped diagnostics.
H2-1. Definition & Page Boundary
What the “master” is (engineering definition)
A Building Intercom Master is the central audio routing and supervision console that terminates multiple indoor/outdoor stations, provides full-duplex talk/listen and paging, and keeps the system stable by controlling audio quality, network reliability, port power policy, and time-stamped event evidence.
This page solves (3)
Audio quality at scale: keep duplex voice usable across multiple endpoints using mic-array front-end + AEC/NS/AGC, with measurable headroom and clipping control.
Deterministic delivery: route voice/control over the internal switch with jitter awareness, prioritization concepts, and clear health counters (no protocol tutorials).
Power + fault isolation: supply and supervise stations via PoE PSE ports with per-port allocation, thermal/over-current behavior, and recoverable retry policy.
This page does NOT solve (explicit non-overlap)
Door-station imaging, door relays, access readers, or endpoint sensor/AI details.
Standalone PoE switch architecture or building-wide network design.
Cloud/app ecosystems, recording platforms, or deep security key management.
Scope rule: every claim must map to a bench-verifiable signal, counter, or event log the master can expose.
Proves whether audio breakup is transport jitter/loss vs codec/DSP artifacts.
PoE & rails
Per-port power draw/allocation, over-current/thermal flags, brownout/UVLO events, rail ripple during port inrush.
Distinguishes port power cycling from endpoint faults and prevents “random reboot” misdiagnosis.
Time & logs
Timestamp monotonicity after reboot, RTC holdover, sync reacquisition time, event reason codes (port off, retry, DSP overload).
Creates a replayable incident timeline for field service without requiring external capture tools.
Figure F1. The master station is best debugged as four coupled subsystems: audio, network, PoE/power, and time-stamped evidence. Each later chapter maps back to one of these verifiable paths.
H2-2. System Roles & Topologies (What connects to what)
Intent
This chapter locks the deployment boundary and turns “topology talk” into a computable design checklist: endpoint scale, concurrent audio load, uplink capacity, PoE budget, latency/jitter targets, and failure domains.
Topologies (device-level view only)
Star (most common): the master directly powers/links multiple stations. Strong fault isolation, but higher port count and concentrated power/thermal design.
Logical chain / tiered extension: used when physical constraints exist. Saves ports, but increases sensitivity to jitter, intermediate outages, and broadcast storms (do not treat it like a free port multiplier).
Non-overlap guard: no building-wide cabling standards and no switch design tutorial. Only the master’s observable behavior and the implications on audio stability.
Topology checklist (inputs that drive later chapters)
Checklist item
Why it matters (what it constrains)
Evidence to log/monitor
Endpoint count (indoor/outdoor)
Determines switch port count, PoE budget, and aggregate control traffic.
Per-port link uptime, disconnect reason codes, endpoint heartbeat failures.
Concurrent calls (duplex streams)
Sets DSP/codec throughput and the latency headroom for AEC + jitter buffering.
Power domain coupling: PoE inrush or overload can corrupt local audio rails unless isolation and policy are defined (shows up as brownout/UVLO + audio artifacts).
Switch domain coupling: a single noisy port (errors/storms) can raise jitter for multiple streams unless containment counters and policies exist.
DSP domain coupling: AEC/NS overload affects all calls simultaneously; overload must be observable and tied to a controlled degradation mode.
Figure F2. Use topology discussions to drive measurable constraints: endpoint scale, duplex concurrency, PoE budget, and where failures “blast” across the system.
A building intercom master is best debugged as a signal-flow system, not a feature list. This chapter defines
where audio can degrade (capture / DSP / transport / playback), and the minimum measurement tap points
that prove which stage is responsible—before any tuning or network changes.
Signal-flow model (debug-first)
Capture chainDSP chainPacketize + bufferDecode + mixAnalog out
Capture: Mic Array → AFE / ADC → (TP1: Mic PCM) → DSP prep.
Scope guard: packetization and buffering are described only as latency/jitter contributors.
No SIP/RTP walkthroughs or “how to configure QoS” tutorials appear in this page.
Full-duplex constraints (what breaks first)
Echo loop alignment: the speaker reference must match the acoustic return path (wrong tap point or delay mismatch yields residual echo).
Latency budget: excessive buffering improves dropouts but degrades duplex “feel” and can destabilize AEC under double-talk.
Double-talk handling: when both ends speak, aggressive suppression can erase near-end speech unless headroom and reference routing are correct.
3 measurement tap points (minimum viable evidence)
TP1 — Mic PCM: proves front-end noise floor, gain mismatch, and clipping before DSP touches the signal.
TP2 — Post-AEC PCM: proves whether residual echo is created by AEC/reference alignment vs later transport artifacts.
TP3 — Post-Decode PCM: proves whether breakup originates from buffering/late packets vs the analog amplifier/speaker chain.
Latency budget (turn “it feels laggy” into accounting)
Stage
What sets it
Typical contributor
Evidence to record
Capture framing
Frame size / hop size at the input; ADC/DMA chunking.
Limiter/thermal flags, rail brownout events during high volume.
Rule of thumb: do not “fix echo” by increasing jitter buffers. Use buffers to stabilize transport, then prove echo alignment at TP2.
Figure F3. Three tap points (TP1/TP2/TP3) separate front-end/DSP defects from transport/buffering and analog output issues without protocol deep-dives.
H2-4. Mic Arrays & Acoustic Front-End (Designing for AEC Success)
Core principle
AEC performance is capped by geometry, front-end noise/headroom, and mechanical/acoustic coupling.
When duplex audio fails, the fastest path is to prove whether the master is limited by
mic mismatch, phase delay, or an uncontrolled echo path—before any DSP parameter changes.
Array geometry choices (engineering trade-offs)
2 mics: lowest cost and simplest; limited spatial discrimination; most sensitive to enclosure resonances.
4 mics: common baseline; workable coverage with moderate calibration effort; good for wall/desk consoles.
6–8 mics: best far-field and robustness; higher channel count and tighter manufacturing/bring-up discipline.
Selection rule: choose mic count from coverage + noise-floor target + enclosure constraints, then verify with TP1/TP2 evidence rather than subjective listening alone.
AFE specs that directly map to symptoms
EIN / noise floor: sets intelligibility in quiet rooms; excessive EIN manifests as constant hiss at far-end.
Dynamic range & clipping margin: prevents “crackling” on loud speech or paging; insufficient headroom triggers AEC instability.
Mic bias & input impedance: poor biasing shows up as unit-to-unit drift or channel imbalance.
Anti-alias bandwidth: too aggressive reduces clarity; too wide risks folding noise into voice band.
Mechanical coupling (what hardware must control)
Porting & leakage: uncontrolled vents and seams create unpredictable echo paths and wind/handling noise.
Vibration: speaker vibration couples into mic capsules and creates non-acoustic “echo-like” artifacts.
Speaker-to-mic path: distance and obstruction matter more than DSP claims—treat as a first-class design parameter.
What must be stable for calibration (concept link only)
Sensitivity mismatch: channel gain differences must be bounded so beamforming/AEC does not chase moving targets.
Phase delay mismatch: stable per-channel delay is required for consistent spatial response and echo alignment.
These stability requirements typically map to stored calibration values; this page focuses on what must be stable and how to prove it, not on storage formats.
Mic array bring-up checklist (evidence-first)
Step 1 — Per-channel noise floor: measure silent-room PCM RMS at TP1 to isolate AFE noise and bias issues.
Step 2 — Gain match: play a fixed tone/speech at fixed distance; compare channel levels; flag outliers before DSP.
Step 3 — Impulse/latency alignment: run a short impulse test; estimate inter-channel delay spread; verify stability across reboots.
Step 4 — Echo path sanity: increase playback volume; confirm the AEC reference path reduces residual echo at TP2 without pumping.
Step 5 — Mechanical sensitivity: tap/handle the enclosure; if artifacts appear at TP1, address vibration/porting before tuning DSP.
Figure F4. AEC success depends on controlling the physical echo loop and the front-end’s noise/headroom. Use TP1/TP2 evidence to separate mechanics from DSP.
This chapter turns “sounds bad” into provable causes: reference pick-off errors, headroom/level control issues,
or real-time overload. It focuses on what to verify (tap points + counters + trends) and the first fix
that restores stable full-duplex—without algorithm lectures.
AEC reference pick-off (the #1 make-or-break detail)
Correct reference: a digital copy of the actual speaker drive signal in the playback path, close to the final output queue/FIFO.
Avoid reference pollution: UI tones/alerts should not “appear/disappear” relative to the reference. Keep routing consistent.
Delay alignment matters: a valid reference with the wrong delay behaves like a wrong reference (residual echo persists at TP2).
Keep it in one timebase: reference and capture must remain coherent (avoid implicit resampling in the critical path).
Evidence rule: if far-end echo persists, prove reference correctness at TP2 before changing suppression strengths.
Artifacts correlate with headroom dips or underruns.
Fix real-time margin (load partitioning/buffer policy) before tuning filters.
Echo only at high volume
Output limiter/thermal flags, TP2 residual vs volume sweep.
Residual echo rises sharply past a limiter threshold.
Align reference after volume/limiter stage (digital), or reduce distortion in the output path.
Figure F6. Pick the reference close to the final speaker drive (digital) and align delay; wrong pick-off points create residual echo or unstable duplex.
H2-6. Multichannel Codec & Audio Routing (Selection and Partitioning)
Goal
This chapter translates system requirements into a channel map, a clock plan, and a routing architecture
that keeps the AEC critical path coherent. The focus is on avoiding hidden resampling and reference pollution,
while keeping analog and digital domains separated at a block level.
H2-7. Ethernet Switch Inside the Master (QoS/VLAN/Multicast—Only What Matters)
Why this matters
In a Building Intercom Master, the internal switch is not “just networking”—it is the traffic junction between
uplink (building LAN) and multiple PoE downlinks (stations/endpoints). Audio reliability depends on keeping
voice/control resilient under microbursts from video and bulk transfers, and on having counters that
prove where loss or jitter originates.
Port roles & traffic patterns (engineer’s mental model)
Uplink port: aggregation point. Microbursts happen when multiple downlinks transmit concurrently (common cause of jitter without full bandwidth saturation).
Downlink ports (PoE): endpoint-facing. Link flaps and CRC/FCS errors are common indicators of cabling, EMI, or power-coupled issues.
Debug principle: if video looks fine but voice breaks, suspect classification/queuing before suspecting raw link speed.
QoS essentials (minimum viable rules)
Priority: voice/control must map to a higher-priority queue than video/bulk.
Jitter vs buffer: shallow buffers drop under bursts; deep buffers raise latency (“slow talkback”). Prefer predictable queueing.
Consistency: classification must be stable across modes; inconsistent marking causes “intermittent” voice artifacts.
Evidence tie-in: prove QoS by logging per-queue drops and queue occupancy (or closest available counters).
VLAN / isolation (concept only)
Segmentation: separate endpoint traffic domains to limit fault propagation (voice/control vs bulk).
Port isolation: prevent endpoint-to-endpoint flooding when not required by topology.
Operational goal: a bad endpoint should not destabilize the whole master via broadcast/multicast spillover.
This page avoids deployment how-tos; it focuses on what isolation is for and how to detect when it fails.
Multicast/broadcast containment (storm-proofing)
Broadcast storms: a single misbehaving device or loop can raise broadcast/unknown-multicast counters and starve voice queues.
Containment goal: unknown multicast/broadcast should not be flooded across all PoE downlinks indiscriminately.
Storm detect flags: if available, treat storm detection as a first-class alarm tied to link/queue telemetry.
Field shortcut: if voice collapses across multiple endpoints simultaneously, check broadcast/multicast rate and storm flags before touching audio tuning.
H2-8. PoE PSE Subsystem & Power Tree (Budgeting, Protection, Graceful Behavior)
Why this matters
The master is a power distributor as well as an A/V hub. PoE port events (detection, inrush, overload, thermal)
can couple into local rails and destabilize audio or switching unless the system enforces a clear
budget, priority shedding policy, and observable power telemetry.
PSE behavior (what must be predictable)
Detection/classification: identify a valid PoE load before enabling power, to avoid wasted retries and false faults.
Per-port allocation: each port has a limit; the system must also respect a total power ceiling.
Priority shedding: when total power approaches limit, shed lower-priority ports first to keep core services stable.
Protection: short/overcurrent/overtemp must produce a clear reason code and a controlled retry schedule.
Design target: PoE port load changes must not cause codec/DSP rails to dip below stability thresholds.
Brownout/overload — keep audio stable when PoE load changes
Audio symptom coupling: buffer underruns, “robotic” voice, or link renegotiations can be downstream of rail dips.
What to prove: correlate PoE total current steps and per-port power changes with local-rail monitors and underrun counters.
Graceful response: reduce or shed low-priority ports before core rails cross a brownout threshold.
Minimum evidence set: total PoE power, per-port power, brownout flag, key rail minima (SoC/codec/switch), reboot reason + timestamp.
Power tree (block-level partition)
Primary input feeds a high-voltage PoE rail for PSE and separate regulated rails for local compute and audio.
PSE rail(s) supply PoE ports; total power monitoring and per-port current sense are essential.
Local rails (codec/SoC/switch/UI) must be protected from PoE load steps via regulation and control policy.
Output — Power budget table template
Item
Priority tier
Limit / class
Typical
Peak / inrush
Overload policy
Port 1
Tier-0
Per-port cap
Typical W
Peak W / inrush note
Protect first; shed last.
Port 2
Tier-1
Per-port cap
Typical W
Peak W / inrush note
Shed before Tier-0 if needed.
Port 3
Tier-2
Per-port cap
Typical W
Peak W / inrush note
Shed first on overload.
Local: SoC/DSP
Core
Rail budget
Typical W
Peak W
Never brown out; protect with policy.
Local: Codec/AFE
Core
Rail budget
Typical W
Peak W
Noise-sensitive; avoid dips/steps.
Local: Switch/PHY
Core
Rail budget
Typical W
Peak W
Prevent link flaps under load steps.
Total PoE
System
Total cap
Typical W
Peak W
Triggers priority shedding stages.
Fill-in guidance: use “Typical/Peak/inrush note” to catch endpoints that destabilize the master during startup, not just steady-state power.
Output — Port fault policy (retry timing + latch-off rules)
Fault type
Immediate action
Retry schedule
Latch-off rule
Event log
Short / severe overcurrent
Fast shutdown + fault code
Backoff retries (increasing delay)
After repeated failures, latch until manual/maintenance window
Port ID + reason + timestamp + peak current
Overload (near limit)
Current limit or controlled shutdown
Retry after cool-down
Latch if thermal or repeated overload persists
Port power + duration + shedding stage
Overtemperature
Reduce/disable port, protect PSE
Retry after temperature falls
Latch if temperature re-trips quickly
Temp + port + PSE state
Undervoltage / brownout
Enter shedding stage, preserve core rails
Recover in stages (avoid all-ports restart)
Latch low-priority ports if repeated brownouts occur
Total power + rail minima + reboot reason
Operational intent: avoid “all ports restart together,” which creates repeated inrush waves and a brownout loop.
Hold-up strategy (clean logging/shutdown, not UPS design)
Trigger: brownout monitor asserts a flag when key rails approach minimum.
Action: flush event logs and mark a last-known-good state before rails collapse.
Goal: preserve timestamps, fault reasons, and avoid corrupted storage/state after power events.
Keep hold-up discussion at block level: supervisor + hold-up energy + log flush.
Figure F8. PoE power events must be observable and policy-driven (allocation, shedding, retries) so local rails remain stable and logs stay trustworthy.
H2-9. Time Sync & Clocking (Logs, Correlation, Scheduled Audio)
Intent
Time in a Building Intercom Master is an engineering dependency: it makes event logs trustworthy,
enables cross-device correlation during incidents, and keeps scheduled paging/call records consistent.
This chapter focuses on what time must prove and how to measure it, without turning into a timing-hub page.
Where time matters (use cases)
Incident correlation: access events, alarms, link faults, PoE port faults, and call actions must align on a single timeline.
Call & paging records: start/answer/end times, retries, and dropouts are only actionable when timestamps are stable.
Distributed paging alignment: scheduled announcements and zone paging should not drift into audible misalignment.
Minimum requirement: event ordering must remain correct under load, offline periods, and reboots.
Options (feature levels)
RTC + NTP (common default): stable wall-time for logs, reasonable alignment across devices, and survivable behavior after reboot.
PTP-capable (optional): tighter inter-device correlation when supported; treat as a feature level, not a deployment tutorial.
Monotonic timer (always): guarantees ordering and durations even if wall-time shifts.
Keep “wall time” for human/audit timelines, and “monotonic time” for ordering and durations.
Offset (avg/max): record average and worst-case offset against the reference over representative load conditions.
Jitter (p95/p99 or peak-to-peak): verify stability; spikes indicate contention, queueing, or time-client instability.
Holdover drift rate: disconnect network time input and log offset growth over time (hours) to characterize RTC holdover.
Timestamp monotonicity: flag any negative time jumps; detect duplicate timestamps for high-rate events.
Reboot continuity: after reboot, confirm wall-time remains plausible and the system marks a new boot/session ID.
Sync reacquisition time: measure time-to-stable-offset after link restoration.
Audit-grade habit: store an incident timeline using wall-time, but verify ordering and durations using monotonic time fields.
Figure F9. Separate audio sampling clock from system wall-time and monotonic time; prove timing quality with offset/jitter, holdover drift, and monotonicity checks.
H2-10. Validation Plan (Bench Tests That Prove It Works)
Intent
This validation plan turns the master station into an engineering-grade deliverable:
each test is defined by setup, metric, pass criteria, and the log fields required to prove outcomes.
It covers worst-case behaviors across audio, networking, PoE power, and timing.
Principles (repeatable across products)
Worst-case first: validate under load, temperature, and port power events—then measure normal conditions.
Evidence-driven: every failure mode must map to a measurable counter, flag, or timestamped record.
Cross-domain correlation: align audio artifacts with network counters and power events using the time evidence checklist.
Figure F10. Validation should converge to a unified evidence log: timestamps + counters + fault codes enable fast root-cause across audio, network, PoE, and time.
This chapter offers a streamlined playbook for diagnosing common issues in a master station using minimal tools. The focus is on providing a decision tree for high-frequency symptoms, accompanied by the first two measurements, the discriminator, and the first fix for each.
Symptom 1: Far-end hears echo / feedback
First 2 Measurements:
Codec input level: Measure the audio signal level on the input of the codec.
ERLE (Echo Return Loss Enhancement) statistic: Monitor the ERLE values to detect the amount of echo suppression.
Discriminator: If ERLE is poor but network errors (such as jitter or packet loss) are not significant, the issue is likely with the acoustic coupling or incorrect AEC (Acoustic Echo Cancellation) reference routing.
First Fix:
AEC reference routing: Adjust the tap points for the echo path to optimize suppression.
Gain staging: Ensure the mic gain is correctly set to avoid audio distortion and feedback.
Symptom 2: Voice breaks up / robotic / choppy
First 2 Measurements:
Codec input/output level: Check for input clipping and ensure the output signal is consistent.
Jitter buffer underrun: Measure the buffer underrun rate to ensure smooth audio transmission.
Discriminator: If the jitter buffer underrun is high, it indicates network congestion or insufficient bandwidth for stable transmission, causing audio to break up.
First Fix:
QoS (Quality of Service) configuration: Ensure that voice traffic is prioritized over bulk data traffic.
Network routing optimization: Check if the network is properly routed for low latency and no packet loss.
Symptom 3: One-way audio (only one side can hear)
First 2 Measurements:
Port power and link status: Verify if the PoE (Power over Ethernet) is supplying power to both the device and the network link.
Packet loss: Check for packet loss on the network.
Discriminator: If there is no packet loss and PoE power is stable, but only one side of the call can hear, it indicates a codec misconfiguration or a failure in the audio path.
First Fix:
Port power policy: Recheck the power supply to ensure proper PoE allocation.
Codec configuration: Verify both transmit and receive channels are configured correctly in the codec.
Symptom 4: Distortion / clipping at high volume
First 2 Measurements:
Codec input/output level: Check for clipping or signal distortion at high volumes.
Signal-to-noise ratio (SNR): Measure the SNR to determine if the distortion is caused by noise.
Discriminator: If clipping occurs at high volumes but the SNR is acceptable, the issue is likely due to insufficient dynamic range or gain setting in the codec.
First Fix:
Gain staging: Adjust the codec input/output gain to prevent clipping.
Audio pipeline check: Ensure the signal path is not overdriven at any stage.
Symptom 5: Call drops when PoE ports power-cycle
First 2 Measurements:
PoE power status: Monitor the power-up sequence for each PoE port.
Link errors: Check for link status changes when the PoE ports are power-cycled.
Discriminator: If call drops coincide with PoE port cycling and link errors occur, the issue is likely power-related.
First Fix:
Power sequencing: Ensure that PoE ports are correctly sequenced for startup and shutdown.
Hold-up strategy: Implement a buffer to hold PoE power for a few milliseconds to avoid abrupt power changes during reboot.
Far-end hears echo only in one room — acoustic path or AEC reference routing? (→H2-4/H2-5)
Answer: If echo is heard only in one room, it may be caused by either improper AEC reference routing or a sound reflection issue in the room. Check the AEC reference tap points and inspect room acoustics (microphone-to-speaker path).
Echo gets worse when volume increases — clipping, AGC pumping, or DSP headroom? (→H2-3/H2-5)
Answer: When echo worsens with volume, check for clipping at the input, AGC pumping, or insufficient DSP headroom. Increase DSP headroom and fine-tune AGC settings to prevent excessive gain adjustments.
Voice breaks up under heavy traffic — QoS issue or jitter buffer too small? (→H2-7/H2-3)
Answer: If voice breaks up under heavy traffic, check if QoS is properly configured to prioritize voice packets. If not, increase the jitter buffer size to handle network delay fluctuations better.
One endpoint frequently disconnects — cabling/EMI or switch port errors? (→H2-7)
Answer: Frequent disconnections could be due to faulty cabling, electromagnetic interference (EMI), or switch port errors. Inspect the cables and check for link errors or port configuration issues in the switch.
PoE ports reboot endpoints randomly — power allocation or thermal limit? (→H2-8)
Answer: PoE port reboots may be caused by power allocation issues or thermal limits. Ensure that PoE power is properly distributed and that thermal protection is functioning as expected.
Paging is delayed across zones — latency budget overflow where? (→H2-3/H2-7)
Answer: Paging delays could be due to latency budget overflow between zones. Review the latency budget for audio and data transmission to ensure that all zones are in sync.
Only some mics sound noisy — mic bias/AFE noise or mechanical leakage? (→H2-4)
Answer: If only some microphones sound noisy, check the mic bias or AFE noise level. Mechanical leakage from mic ports or poor sealing could also cause interference.
AEC works until firmware update — channel map/clocking changed? (→H2-6/H2-5)
Answer: If AEC stops working after a firmware update, check if the channel map or clocking configuration was altered. Restoring the previous settings can fix this issue.
Timestamps jump after reboot — RTC holdover or time sync reacquisition? (→H2-9)
Answer: If timestamps jump after reboot, check for RTC holdover or time synchronization reacquisition issues. Ensure that the RTC is correctly maintaining time during power cycles.
Audio is clean but low volume — gain staging or amp power rail sag? (→H2-6/H2-8)
Answer: Low volume despite clean audio could be due to improper gain staging or amp power rail sag. Check the gain settings and ensure that the amplifier is receiving adequate power.
Intermittent howling — feedback loop vs beamforming steering mismatch? (→H2-4/H2-5)
Answer: Intermittent howling could be due to a feedback loop or a mismatch in beamforming steering. Adjust the microphone array configuration and verify the beamforming settings.
Event logs show call ended, but user reports ongoing audio — what evidence proves packet path failure? (→H2-7/H2-11)
Answer: If event logs indicate that the call has ended but the user reports ongoing audio, check for packet path failures. Inspect the event logs for packet loss or jitter issues.
