Overview¶

Overview¶

This guide covers the local audio subsystem on SF32 devices — the codec, DMA, and middleware path used for microphone input, speaker/line output, and on-device playback or recording. It focuses on practical decisions: interface selection, buffering strategy, the Audio Server middleware, codec choice, and power.

Bluetooth audio (A2DP, LE Audio) is a related but separate topic covered in the Bluetooth Overview — that page covers the wireless streaming side, while this one covers what happens once samples are on-chip: capture, mixing, decoding, and driving the physical audio path.

Use this page when selecting the microphone, codec, buffering, and power strategy for a product—not merely when an audio demo needs to play once. It is written for engineers who must make the audio path reliable alongside Bluetooth, display, storage, and battery constraints.

Define the Product's Audio Requirements¶

Before choosing interfaces or buffer sizes, pin down what the product needs:

• Playback only, recording only, or both simultaneously (full duplex)?
• How many microphones, and analog (AMIC) or digital (DMIC)?
• Local playback formats — raw PCM, MP3, Opus, or another codec?
• Is Bluetooth audio (Classic or LE Audio) also required, in parallel with local audio?
• Voice-trigger or always-listening behavior, and its power budget?
• Speaker/line-out drive requirements, or is output routed to an external amplifier/codec?
• Latency tolerance — voice calls and real-time monitoring are far stricter than notification chimes.

These answers determine the interface (I2S vs. PDM vs. ADC/DAC), the codec configuration, and how much of the pipeline needs to stay awake.

The SF32 Audio Signal Path¶

A typical SF32 local-audio pipeline looks like this:

Microphone(s) (AMIC / DMIC)
        │
        ▼
AUDCODEC (analog front end, ADC/DAC)
        │
        ▼
AUDPRC (audio processing: mixing, gain, sample-rate handling)
        │
        ▼
Audio Server (middleware: stream routing, playback/record sessions)
        │
        ▼
Application (playback engine, voice pipeline, Bluetooth audio bridge)
        │
        ▼
Speaker / Line-out / DAC, or onward to Bluetooth audio

AUDCODEC is the analog front end — the ADC/DAC hardware that converts between analog audio and digital samples. AUDPRC sits above it and handles processing tasks such as mixing, gain, and format/sample-rate handling. The Audio Server middleware coordinates playback and recording sessions on top of both, so application code generally works with streams and sessions rather than programming the codec registers directly.

Choosing Interfaces: AMIC, DMIC, and I2S¶

Mixing AMIC and DMIC inputs is common in multi-microphone designs (for example, one AMIC for general capture and multiple DMICs for a voice-focused array) — confirm exactly how many of each the target device supports before finalizing the microphone layout.

Pick the Right SF32 Device¶

Audio capability varies across the family — check the datasheet for the exact part, but as a starting point:

See the SF32 Family Overview for the full chip comparison, and confirm exact AMIC/DMIC counts against the datasheet before finalizing a design — this table reflects current front-page positioning, not a substitute for the datasheet.

Audio Session Templates¶

Most products fall into a few repeatable session shapes. Choose the closest one and validate it explicitly:

Define start, steady-state, underrun/overrun recovery, and teardown behavior for each session. Audio bugs often hide in transitions rather than in the steady playback loop.

Buffer and Latency Budget¶

Buffer size is a product decision, not just a driver default. Use the formula:

latency per buffer = samples per buffer / sample rate

For example, a 480-sample buffer at 48 kHz represents 10 ms of audio before any decoding, scheduling, or transport delay. Double buffering improves safety but also adds pipeline depth. For voice interaction and calls, define the total latency budget first and then divide it across capture, processing, Bluetooth/transport, playback, and scheduling.

Playback and Recording Basics¶

Whether driving a speaker or capturing a microphone, the same fundamentals apply:

• Buffer sizing — small buffers reduce latency but increase interrupt/DMA overhead; large buffers are more forgiving but add latency and use more memory.
• DMA-driven transfer — audio should move via DMA rather than CPU-copied sample loops, freeing the CPU for UI, Bluetooth, and application logic.
• Sample-rate and format planning — decide sample rate (e.g., 16 kHz for voice, 44.1/48 kHz for music) and bit depth up front; converting formats at runtime costs CPU and memory.
• Double buffering — use at least two buffers so one can be filled by the application while the other is being transferred by DMA, avoiding underruns and glitches.

Cache-coherency rules apply here just as with graphics and AI buffers: if AUDCODEC/DMA and the CPU share a buffer, follow the SDK's cache clean/invalidate rules before handing the buffer between them.

Codec and Compression Choices¶

Raw PCM is simplest but uses the most memory and storage bandwidth. For playback from Flash/PSRAM or storage, compressed formats reduce footprint at the cost of decode complexity:

The SDK includes example projects for local music playback (including an SD-card MP3 player), Opus playback, dual ADC/DAC audio paths, and recording — start from the closest example rather than building the pipeline from scratch.

Local Audio vs. Bluetooth Audio¶

Keep the two paths conceptually separate, even though they may run concurrently:

• Local audio (this guide) — AUDCODEC/AUDPRC, microphones, speaker/line-out, on-device playback and recording.
• Bluetooth audio (Bluetooth Overview) — A2DP/AVRCP/HFP for Classic, or LE Audio broadcast for BLE.

Many real products bridge the two — for example, capturing on a local microphone and streaming over Bluetooth, or receiving Bluetooth audio and mixing it with a local notification chime through the Audio Server. Plan buffer ownership and mixing behavior explicitly when both paths are active at once.

Board-Level Audio Checklist¶

Firmware cannot fully hide poor analog design. Review these items during schematic and PCB work:

For products with both RF and analog audio, validate noise with Bluetooth active, display refreshing, charger connected, and the final enclosure assembled.

Power Considerations for Audio¶

Audio is one of the more power-hungry always-on workloads on a battery-powered device:

• Keep the codec and DMA path active only while audio is actually flowing; return to a low-power state between playback/record sessions.
• For always-listening voice-trigger designs, prefer the lowest-power capture path the SDK and device support, and keep the trigger model as lightweight as possible — see the AI Overview for the inference side of this.
• Batch or buffer aggressively enough to avoid waking the application CPU for every sample block; let DMA and interrupts do the routine work.
• Coordinate audio timing with Bluetooth and display activity — see Low-Power Overview and Bluetooth Overview: Coexistence for the system-level view.

Audio Validation Matrix¶

Run the same audio tests after codec, Bluetooth, display, power, or clock changes:

Keep a known-good reference WAV/PCM file and a known-good captured sample from the evaluation board. They make regressions much easier to identify than subjective listening alone.

Debugging Audio Issues¶

Common Mistakes¶

• Programming the CPU to copy audio samples instead of using DMA.
• Choosing a single, undersized buffer instead of double buffering.
• Mixing AMIC and DMIC assumptions without checking the target device's actual microphone interface count.
• Treating Bluetooth audio and local audio as fully independent when they'll run concurrently in the real product.
• Ignoring cache-coherency rules for buffers shared between AUDCODEC/DMA and the CPU.
• Leaving the codec and DMA path powered between sessions instead of tearing it down.
• Committing to a compressed format before confirming decode cost fits the power and CPU budget.

Bring-Up Checklist¶

• Confirm microphone type(s) (AMIC/DMIC) and count against the target device's datasheet.
• Decide sample rate, bit depth, and buffer sizes for playback and recording paths.
• Bring up AUDCODEC/AUDPRC and validate a basic playback and recording loop.
• Integrate with the Audio Server middleware rather than driving the codec directly from application code.
• Choose and validate the compression format (PCM/MP3/Opus) against decode-cost and memory budgets.
• Validate cache clean/invalidate behavior for buffers shared with DMA.
• Test local audio and Bluetooth audio running concurrently, if both are used.
• Profile power during active playback/recording and confirm the codec path powers down between sessions.

Key Takeaways¶

• The local audio path runs through AUDCODEC (analog front end) and AUDPRC (processing), coordinated by the Audio Server middleware — build on top of that middleware rather than the raw codec registers.
• Choose AMIC, DMIC, or I2S based on the target device's actual interface count and the product's microphone layout, not assumptions carried over from another chip.
• DMA-driven, double-buffered transfer is the baseline for glitch-free playback and recording.
• Local audio and Bluetooth audio are separate subsystems that often need to run together — plan mixing and buffer ownership explicitly.
• Treat audio power the same way as Bluetooth and AI power: minimize active time, avoid unnecessary CPU wakeups, and measure real sessions, not just steady-state playback.