Writing Your Own CODEC Driver — Part 2: DAC Playback

Connect a DAC and it just plays — what does the software need to do?

Last article covered the PDM microphone — the chip needs no control, configure DTS and it records. This time we flip the direction — playback.

Many DAC chips are just as "hands-off": no control interface required, connect the I2S data lines and power, and they output sound. Hardware engineers love these — zero effort. So on Linux, if we pair such a DAC with a dummy-codec, how many lines of driver code do we need to write to play audio?

The answer is the same as last time: zero. But this time we flip the DAI direction.

Key points

1. Playback direction = the DAI declares .playback, the sound card exposes /dev/snd/pcmC0D0p.
2. DACs like PCM5102A have an internal PLL — they derive their own clock from BCLK, so no MCLK is needed. Truly zero-control playback.
3. The .playback capability declaration in dummy-codec is what this article covers. DTS is still the same three-piece combo. aplay plays directly.

1. First, the direction: PLAYBACK vs CAPTURE

Part 1 (PDM mic) was the capture direction — data flows into the SoC — and the sound card exposed pcmC0D0c. This time we flip to the other side — playback — data flows out of the SoC:

Recall the DAI capability summary from Part 1:

struct snd_soc_dai_driver {
        .playback = { ... },    /* declared = this stream exists = /dev/snd/pcmC0D0p */
        .capture  = { ... },    /* declared = this stream exists = /dev/snd/pcmC0D0c */
};

• Part 1 (PDM mic): pure capture
• This article (DAC): pure playback
• Part 5 (rk730): both directions

2. The star: a DAC that needs no control at all

Take TI's PCM5102A — a familiar face in the HiFi world, used on many audio boards. Look at its hardware "requirements list":

Power it up, feed it I2S data, it makes sound. Even more hands-off than the PDM mic — you don't even have to think about "I must give it a clock" (BCLK comes with I2S anyway).

The kernel already has a dedicated driver for this chip — sound/soc/codecs/pcm5102a.c, 57 lines total. The core is a single capability declaration:

static struct snd_soc_dai_driver pcm5102a_dai = {
  .name = "pcm5102a-hifi",
  .playback = {                              /* NOTE: playback only! */
    .channels_min = 2,
    .channels_max = 2,
    .rates = SNDRV_PCM_RATE_8000_384000,
    .formats = SNDRV_PCM_FMTBIT_S16_LE |
         SNDRV_PCM_FMTBIT_S24_LE |
         SNDRV_PCM_FMTBIT_S32_LE
  },
};

static int pcm5102a_probe(struct platform_device *pdev)
{
  return devm_snd_soc_register_component(&pdev->dev, &soc_component_dev_pcm5102a,
      &pcm5102a_dai, 1);
}

That's it: declare "I can play 2 channels", then register. But you don't even need it — dummy-codec declares both .playback and .capture, so it covers PCM5102A's slot more than adequately. The chip needs no control anyway, so the codec driver is just a placeholder — and any placeholder will do.

The .playback portion in dummy_dai

Part 1 looked at dummy-codec.c's .capture (lines 60–70). This article symmetrically looks at its playback declaration (source lines 49–59):

struct snd_soc_dai_driver dummy_dai = {
  .name = "dummy_codec",
  .playback = {                           /* ← Playback capability: this article's focus */
    .stream_name = "Dummy Playback",  /* stream name */
    .channels_min = 1,                /* min 1 channel */
    .channels_max = 384,              /* max 384 channels */
    .rates = SNDRV_PCM_RATE_CONTINUOUS,  /* any sample rate */
    .formats = (SNDRV_PCM_FMTBIT_S8 |
          SNDRV_PCM_FMTBIT_S16_LE |
          SNDRV_PCM_FMTBIT_S20_3LE |
          SNDRV_PCM_FMTBIT_S24_LE |
          SNDRV_PCM_FMTBIT_S32_LE),  /* bit depth S8 ~ S32 */
  },
  ...                                     /* .capture was covered in Part 1 */
};

Symmetric to .capture character-for-character, just the stream_name changes to "Dummy Playback". With this block present, pcmC0D0p is created and aplay can open it.

Compared with PCM5102A's declaration, the only difference is "guts":

A real chip driver's capability declaration must stick to the datasheet — over-declare and applications crash on open. dummy doesn't connect a real chip, so over-declaring is fine; the CPU DAI side enforces the real constraints.

3. DTS configuration: still the three-piece combo

Same recipe as Part 1's PDM, just a different interface and direction:

/* ① Codec DAI: dummy-codec placeholder (same driver as Part 1) */
dummy_codec: dummy-codec {
  status = "okay";
  compatible = "rockchip,dummy-codec";
  #sound-dai-cells = <0>;
};

/* ② CPU DAI: enable the I2S controller + pin mux */
&i2s0 {
  status = "okay";
  pinctrl-names = "default";
  pinctrl-0 = <&i2s0m0_sclk &i2s0m0_lrck
         &i2s0m0_sdi0 &i2s0m0_sdo0>;  /* BCLK / LRCK / data lines */
};

/* ③ Machine: assemble the sound card */
dummy_sound: dummy-sound {
  status = "okay";
  compatible = "rockchip,multicodecs-card";
  rockchip,card-name = "rockchip-dummy";    /* sound-card name */
  rockchip,format = "i2s";                  /* data format */
  rockchip,cpu = <&i2s0>;                   /* CPU DAI = I2S controller */
  rockchip,codec = <&dummy_codec>;          /* Codec DAI = dummy */
};

Two things change vs. Part 1:

The three-piece structure is identical — that's the value of the framework. Change direction, change interface, the recipe stays.

4. Playback verification

# 1. Sound card registered
cat /proc/asound/cards
#  0 [dummy         ]: rockchip-dummy

# 2. Device node — this time it's the playback (p)
ls /dev/snd/
#  controlC0  pcmC0D0p  timer

# 3. Play
aplay -D hw:0,0 -c 2 -r 48000 -f S16_LE /tmp/sine.wav
# Android: tinyplay /tmp/sine.wav

# 4. Check the file parameters match
ls -l /tmp/sine.wav
# 48000Hz × 2ch × 2 bytes, matches aplay's arguments

The data flow is the exact reverse of Part 1:

5. Recap: still zero lines of driver code written

Across both articles, one capture and one playback, we've covered Part 1's .capture and this article's .playback — dummy-codec's capability declarations are now fully explained. The rest of the code (startup / probe) has not been touched, and you've only written DTS.

But not all hardware is this easy:

• Some DACs / codecs have no internal PLL — they must be fed MCLK, and they prefer "clock on only while a stream is active" for power saving.
• The on-board amplifier has an enable pin (SPK-CTL); the headphone jack has insertion detect (HPDET). Switch timing matters.
• Some chips power up in an unknown state — a reset pulse is required before they work.

These are exactly the places where a driver "does something" with signals. The next article answers: where in the code do MCLK, SPK-CTL, RESET live? dummy-codec.c's remaining startup and probe finally come on stage.

Series preview — "How to write your own CODEC driver"

This article is Part 2 of the series. Source code is based on the Rockchip BSP kernel 6.1 (v6.1.162) — taking you from the hardware all the way up to advanced DAPM architecture.

• Part 3: Making the driver "move" — coordinating MCLK, RESET, and board-level GPIOs. The three core signals of driver initialization: startup opens MCLK, probe resets, Machine handles board GPIOs.
• Part 4: Refuse DAPM? The "brute-force" register-list transplant — using ES7202 as an example. Skip the complex machinery; copy the IIC config list directly for a quick basic implementation.
• Part 5 (final): From "works" to "advanced" — reshaping with DAPM and Mixer architecture. Add DAPM and Mixer controls for proper bi-directional audio stream control.

Source files referenced: sound/soc/codecs/pcm5102a.c (comparison) and dummy-codec.c.