Audio and Voice Interaction on RK3588: Interfaces, Microphone Arrays and Echo Cancellation (2026)

Key takeaway: audio is not just "wire up a speaker" — it is three chains (capture, processing, playback) plus system clock coordination. Poor pickup, unresolvable echo and audio paths fighting each other almost always come from the joints between those chains, not from swapping in a "better speaker".

1. Know your audio interfaces

Interface	Characteristics	Typical use
I2S / TDM	Standard digital audio link; TDM carries multiple channels on one clock set	Audio codecs, amplifiers, multi-channel I/O
PDM	Two-wire (clock + data), simple routing, well suited to multiple digital mics	Microphone arrays, multi-mic pickup
PCM / TDM voice	Narrowband audio path for voice communication	Communication modules, Bluetooth voice paths
SPDIF	Digital audio in/out	Amplifiers, home-theatre-class peripherals
HDMI / eDP / DP audio	Carried alongside the display link	All-in-one terminals, display audio output
USB Audio	Driver-free, plug-and-play, ample bandwidth	USB mics, sound cards, conference speakerphones
Analog Line-in / Line-out	Requires codec conversion; mind level and impedance matching	Legacy audio compatibility, direct amplifier drive

A good selection order: decide how you capture, then how you play out, and only then derive the interface resources and clock structure you need.

2. The full voice interaction chain

• Capture: microphone (single or array) → preamp → ADC/PDM acquisition;
• Front-end processing: echo cancellation (AEC), noise suppression (NS), automatic gain control (AGC), beamforming, dereverberation. This stage determines whether you can be heard clearly;
• Recognition and understanding: wake-word detection → ASR → NLU, on-device with small models or in the cloud;
• Synthesis and playback: TTS → amplifier → speaker, with the playback signal fed back as the AEC reference.

The weakest link is usually front-end processing: it depends on both hardware (mic consistency, array geometry) and software (algorithm tuning). Either side failing degrades the whole experience.

3. Microphone array hardware essentials

• PDM or I2S: PDM is first choice for multiple digital mics (simple routing, independent channels); use I2S/TDM for high SNR or specific codecs;
• Clock synchronisation: all mics must share one clock — sampling jitter directly destroys beamforming and AEC performance;
• Spacing and geometry: spacing relates to the target frequency band — too wide causes spatial aliasing at high frequencies, too narrow weakens low-frequency directivity. Choose linear or circular arrays by scenario;
• Mechanics and openings: hole diameter, depth and mesh all affect frequency response; test seams and wind noise on the prototype;
• Isolation and protection: filter mic power and digital lines so Wi-Fi/switching-supply noise does not couple in — once it enters the capture chain, it cannot be removed.

4. Why AEC is the hardest part

• Complex acoustic path: speaker sound reflects off the enclosure, desk and walls back to the mic — a time-varying transfer function;
• The reference must be accurate: AEC needs the "about to play" signal. Whether the reference is taken before or after the amplifier, and whether extra gain or EQ is applied, changes cancellation performance;
• Latency must be aligned: if the delay between playback and capture chains drifts, AEC loses lock. Sample-rate conversion, buffer settings and driver paths must be consistent;
• Nonlinearity: amplifier and speaker nonlinearity and clipping at high volume leave residual echo that linear AEC cannot remove — pair it with mechanical isolation (damping between mic and speaker, physical separation, chamber isolation).

Rule of thumb: AEC is half algorithm, half mechanics and component choice.

5. System and software stack

• Driver framework: ALSA/ASoC on Linux — get the DAI link configuration right (master/slave, clock dividers, sample rates) and match the codec driver;
• Audio clocks: plan MCLK/BCLK/LRCK distribution and dividers once. When multiple audio paths share clocks, keep sample rates consistent or add asynchronous sample-rate conversion (ASRC);
• Routing and mixing: multiple outputs (local speaker + HDMI audio + Bluetooth) need a routing policy to avoid preemption and crosstalk;
• Low latency: intercom and voice interaction are sensitive to end-to-end delay — tune buffers, processing chains and thread priorities together;
• Algorithm placement: whether front-end algorithms (AEC/NS/beamforming) run on the CPU or a DSP/NPU determines power budget and concurrent channel count. Decide this at design time.

6. Scenario mapping

• Conference all-in-one / meeting terminals: far-field pickup + strong AEC + beamforming, usually array mics with an omnidirectional speaker, and careful chamber isolation. See Video Conference All-in-One;
• Building intercom / access panels: mostly near-field — pickup in a weatherproof housing and howling suppression for hands-free calls. See Building Intercom & Access Control;
• Voice robots / AMRs: the device has its own fan and motor noise; noise suppression and directional pickup are key, plus control of self-generated mechanical noise;
• Voice recorders / translators / learning devices: multi-mic directional pickup with low power — battery life against algorithm complexity;
• Digital signage / advertising displays: primarily playback — amplifier power, protection and tonal consistency. See Digital Signage & Advertising Display.

7. Common pitfalls

• Myth 1: pick the algorithm, then the hardware. Algorithm performance is bounded by mic consistency, array geometry and mechanics — wrong hardware cannot be rescued by better software;
• Myth 2: AEC is a software problem. Speaker-to-mic acoustic coupling is physical; isolation and spacing design are not optional;
• Myth 3: ignore audio clocks. Clock drift is inaudible short-term but slowly breaks AEC and beamforming — it shows up as "performance degrades over time";
• Myth 4: skip objective measurements on prototypes. Measure frequency response, distortion, noise floor and echo suppression ratio rather than trusting "it sounds fine".

8. FAQ

• Q1: How many audio channels can RK3588 support? It depends on carrier design and interface allocation — the mix of I2S/TDM and PDM significantly affects how many channels are feasible. Confirm per project at review.
• Q2: How many mics for an array? Two mics often suffice for near-field hands-free; far-field conferencing, source localisation or directional pickup usually need more channels. Decide by pickup distance and scenario — more is not automatically better.
• Q3: Can we implement the audio front-end ourselves? Yes, but AEC/noise-suppression work is substantial and tuning depends on the real acoustic environment. Confirm with your vendor which audio components and tuning support are available.
• Q4: Video plays audio over HDMI while the local speaker also plays — will they conflict? They need audio routing and policy — set priorities or mix at the system level. Plan it together at design time.
• Q5: How do we quickly judge whether a design is sound? Tell Hongyin Technology your use case (pickup distance, ambient noise, hands-free or not, speaker power) and receive an audio chain recommendation and hardware configuration within 48 hours.

9. Related solutions & contact

Related solutions: Video Conference All-in-One、Building Intercom & Access Control、Digital Signage & Advertising Display. Further reading: Embedded OS Selection、RK3588 vs RK3576 vs RK3568 Selection Guide、RK3588 Carrier Hardware Design Review Checklist.

Shenzhen Hongyin Technology Co., Ltd. (HONGYIN TECH) provides embedded project customization on RK3588/RK3576/RK3568 platforms — free requirement review, engineer-direct communication and low-volume ordering. Send your requirement list and receive selection advice and quotes within 48 hours.
phone +86 13728726926 | email sales@hoyin-tech.com | website www.hoyin-tech.com | address: Room 301, Building A, Fanrong Science Park, Sanwei Community, Hangcheng Street, Bao'an District, Shenzhen, China.