Audio / FIELD NOTES

Audio bring-up: from clocks to continuous playback

Development currently uses the P4 module’s onboard ES8311 for testing. The new PCB adds a 4-inch ILI TFT, PCM5102 and ES8388; its board specification will be created when the PCB arrives from JLCPCB.

Identify the actual output device

The module’s onboard ES8311 is the current test device. The new custom PCB carries an additional 4-inch ILI TFT, PCM5102 and ES8388. Alan has not yet created its board specification and will do so when the PCB arrives from JLCPCB. The difference between the test firmware and new PCB is an intentional development stage.

When bringing up the new board, define its pin map, display configuration and codec drivers against the schematic, then test each output separately. The main project article separates the existing test path from the planned new-board configuration.

Check clocks before a network stream

Start with low-level local PCM playback at a conservative output level. Confirm BCLK, LRCK, data and any required MCLK against the codec data sheet. Check left/right mapping and sample format. Avoid connecting an unqualified line output directly to headphones; use the intended powered input or amplifier.

Write down the board revision and actual pin map. Treat silence, clipping, swapped channels and intermittent output as separate observations. Do not try to compensate for a clock or format error by changing several unrelated buffer thresholds.

Separate jitter from output pacing

With local playback stable, add the receiver pipeline. Correlate packet arrival, decoder success, queued frames and I²S consumption. An underrun after an artwork update is evidence worth investigating, but it does not by itself establish that the display caused it. Repeat tests with a fixed sender and then vary one load at a time.

The current source uses I²S writes for playback pacing and a non-blocking PCM5102 mirror in BOTH mode. Test whether the secondary output remains continuous under load; do not infer synchronisation quality merely from the presence of both outputs.

Keep a small test matrix

For each run, record firmware commit, dependency versions, board revision, C6 image, sender/device version, stream format, duration, reconnection result and dropouts. Include metadata-only changes, large artwork, stop/start, sender disconnect and wireless loss. Mark untested combinations explicitly.

Read the full architecture and build article → · Inspect the source →

← All articlesSource & downloads ↗