{"id":499421,"date":"2026-10-20T14:39:47","date_gmt":"2026-10-20T11:39:47","guid":{"rendered":"https:\/\/savepearlharbor.com\/?p=499421"},"modified":"2026-10-20T14:39:47","modified_gmt":"2026-10-20T11:39:47","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=499421","title":{"rendered":"Implementation of the HDA Link interface on RP2040"},"content":{"rendered":"
\n

\u0420\u0443\u0441\u0441\u043a\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f<\/a><\/p>\n

When it comes to outputting or inputting audio to or from a microcontroller \u2014 if the system is even slightly more complex than a simple beeper \u2014 I\u00b2S<\/strong> is almost always the standard. Many microcontrollers have the necessary peripherals, and a wide range of compatible audio DACs and ADCs is available. However, this typically means a maximum of 2 channels for audio output and 2 for input (and even then, not always simultaneously).<\/p>\n

On the other hand, there is a whole world called High Definition Audio<\/a>, developed by Intel in 2004. It is highly likely that the sound on the PC or laptop you are using to read this article is transmitted via this interface. HDA supports 15 input channels and 15 output channels, with a bit depth of up to 32 bits and a sampling rate of up to 192\u00a0kHz. Admittedly, not all at once \u2014 the channel bandwidth is limited to just over 46 Mbit\/s per audio output channel; nevertheless, its capabilities are much broader than those of I\u00b2S.<\/p>\n

But I haven\u2019t come across any microcontrollers that natively support HDA. For some reason, it\u2019s generally assumed that only chipsets (south bridges) \u2014 that is, the \u201cfull-fledged\u201d system logic of a PC \u2014 can act as hosts. You could also cobble something together using an FPGA, but for many \u201cknee-on-the-floor DIY\u201d enthusiasts, that\u2019s too high a hurdle.<\/p>\n

I thought that way for a long time, too. And at first, the news about the release of the RP2040 just went right over my head \u2014 I figured, \u201cJust another microcontroller; there are thousands of them.\u201d That is, until I stumbled upon the ZX_RGBI2VGA-HDMI<\/a> project, where this microcontroller captures an RGB video signal from a ZX Spectrum in real time and outputs it as an HDMI (or rather, pseudo-HDMI) signal required by modern monitors.<\/p>\n

And I thought: Why not try an HDA link on it? Well, if not, then not, I told myself,<\/s> and got to work \u2014 luckily, I still had a board with that codec, the ALC889, left over from my previous attempt.<\/p>\n

\"What's<\/p>\n
What’s Left of the Previous Project<\/figcaption><\/div>\n<\/figure>\n\n

HDA-Link Basics<\/h3>\n

Lines and Data Transmission<\/h4>\n

HDA link<\/strong>, also known as Azalia<\/em>, is a simple interface that uses only 4 wires to transmit audio data, but it\u2019s tricky and has specific requirements. The first problem is that the BCLK<\/strong> clock signal must be exactly 24\u00a0MHz \u2014 the PLL inside the codec relies on it. This means you can\u2019t just generate a clock signal via GPIO, as you would for SPI or I\u00b2C, because you need a stable, meander waveform, like the one from a generator.<\/p>\n

<\/figure>\n

The next two signals \u2014 SYNC<\/strong> and SDO<\/strong> \u2014 operate synchronously, and their state can change on every BCLK edge, that is, at a frequency of 48\u00a0MHz (pure DDR). The output is divided into frames of 1,000 bits each, resulting in a frame rate of 48\u00a0kHz \u2014 this is the base audio sampling rate, with each frame representing a single sample. The other frequencies, 96 and 192, are obtained by doubling or quadrupling the number of samples per frame. As for the frequencies derived from CDs and based on 44.1\u00a0kHz, they are calculated the same way, except that for every 160 frames, 13 empty frames (without audio data) must be transmitted, and these 13 empty frames must be evenly distributed throughout the 160 frames.<\/p>\n

The start of the frame \u2014 or, more precisely, its end \u2014 is determined by the SYNC signal; at that moment, a sequence of 8 ones is transmitted there. <\/p>\n

\"Start<\/p>\n
Start of Frame<\/figcaption><\/div>\n<\/figure>\n

The first 40 bits of each frame on the SDO line are reserved for control sequences, known as \u201cverbs.\u201d When the host needs to configure the codec or request something from it, such a sequence is inserted into the stream; otherwise, zeros are transmitted there. Only one verb can be transmitted in each 48\u00a0kHz frame, but this needs to be done infrequently, so there are no issues here. <\/p>\n

The SYNC signal also contains markers that indicate the numbered streams for each stereo channel. After each such SYNC marker, data transmission for that channel begins on the SDO line.<\/p>\n

The last signal, SDI<\/strong>, differs from SDO. Its state changes only on the rising edge of BCLK, meaning its bandwidth is half that of SDO. In addition, the tags for each stereo channel are carried within the signal itself, which further narrows the bandwidth. And at the beginning of each frame, the first 36 bits are reserved for responses. A response may or may not be present \u2014 this is determined by the \u201cvalid\u201d bit. Responses can be either solicited (a response to a command) or unsolicited (a reaction, for example, to plugging a jack into a socket).<\/p>\n

The specified SDO bandwidth allows for the tight fit of 10 channels of 24-bit audio at 192\u00a0kHz \u2014 which is exactly how many (5 stereo channels) are supported by the ALC889 codec. The situation with SDI is a bit more disappointing \u2014 3 stereo channels at 24\/192 don\u2019t fit within the bandwidth, so something has to be sacrificed \u2014 either the sample rate, the bit depth, or the number of channels. Why Intel did this is a mystery to me. Apparently, they decided that 640 KB<\/s> 4 channels would be enough for everyone.<\/p>\n

Codec address<\/h4>\n

For the codec to work, it\u2019s not enough to generate all the signals. You need to take the penultimate step and assign it an address on the bus, which will then be used in all verb requests. Without this, the codec won\u2019t respond to them.<\/p>\n

\"Codec<\/p>\n
Codec initialisation: reset, codec address (CAD)<\/figcaption><\/div>\n<\/figure>\n

Here\u2019s how it works:<\/p>\n