DisplayPort Audio Encapsulation in Secondary Data Packets

This article provides an architectural overview of how digital audio is multiplexed and transported across the DisplayPort Main Link. During horizontal and vertical blanking intervals, audio samples are organized into specialized Secondary Data Packets (SDPs) alongside timestamp and metadata packets. The following sections break down the packet architecture, the framing mechanisms used during blanking periods, sub-packet payload structures, and how raw IEC 60958 audio frames are mapped to link lanes for reliable receiver reconstruction.

The Role of Blanking Periods

DisplayPort organizes high-speed data transmission across the Main Link into active pixel periods and blanking intervals (Horizontal Blanking and Vertical Blanking). While active intervals carry raw pixel data, blanking intervals carry non-video payloads, link framing controls, and Secondary Data Packets (SDPs).

Because audio is a continuous, lower-bandwidth stream compared to video, it does not require dedicated physical lines. Instead, the DisplayPort transmitter buffers incoming audio samples, packages them into SDPs, and injects them into the Main Link during these blanking windows.

Packet Framing and Demarcation

Secondary Data Packets are multiplexed into the physical lanes using specific control symbols (K-codes in 8b/10b encoding or control markers in 128b/132b encoding):

  1. Secondary Data Start (SS): The transmission of an SDP is signaled by an SS control symbol (K28.2 in 8b/10b encoding).
  2. Packet Header: Immediately following the SS marker is a 4-byte header consisting of:
    • HB0 (Packet Type): Identifies the SDP type. For example, 02h denotes an Audio Stream Packet, and 01h denotes an Audio Timestamp Packet.
    • HB1 (Payload Control): Details payload formatting, such as channel mappings or sample presence.
    • HB2 and HB3: Reserve bits and store Parity/Error Correction Code (ECC) bytes calculated across the header.
  3. Packet Payload: A 32-byte payload field organized into four 8-byte sub-packets.
  4. Secondary Data End (SE): Concludes the SDP via an SE control symbol (K28.5) or an SS symbol denoting the immediate start of another packet.

Audio Stream Packet (ASP) Architecture

The primary vehicle for transporting audio data is the Audio Stream Packet (ASP). DisplayPort audio formatting adheres to standard digital audio paradigms, typically wrapping IEC 60958 (LPCM) or IEC 61937 (compressed bitstreams such as Dolby or DTS) formats.

Sub-Packet Organization

An ASP payload is strictly fixed at 32 bytes, partitioned into four 8-byte sub-packets:

  • Sub-packet 0: Bytes 0 to 7
  • Sub-packet 1: Bytes 8 to 15
  • Sub-packet 2: Bytes 16 to 23
  • Sub-packet 3: Bytes 24 to 31

Each 8-byte sub-packet can carry one audio sample per channel pair or be split to support multiple channels. For a standard 2-channel stereo stream, a single sub-packet holds one audio sample (left and right channel), leaving the remaining sub-packets to either carry subsequent samples or remain inactive (marked via control flags in header byte HB1). For multi-channel audio (up to 8 channels in legacy DP, and up to 32 channels in modern specifications), the sub-packets are allocated across channel pairs (e.g., Channels 1/2, Channels 3/4, Channels 5/6, and Channels 7/8).

IEC 60958 Sub-frame Mapping

Each individual audio sample within a sub-packet mirrors an IEC 60958 sub-frame:

  • Audio Data: 16-bit to 24-bit linear PCM audio sample bits.
  • Control and Status Bits:
    • V (Validity Bit): Indicates if the sample is valid and suitable for conversion to an analog signal.
    • U (User Data Bit): Transports user-defined metadata.
    • C (Channel Status Bit): Carries configuration parameters such as sampling frequency, copy protection status, and emphasis.
    • P (Parity Bit): Provides even parity over the sub-frame to detect transmission errors.
  • Preamble Replacement: In standard IEC 60958 S/PDIF streams, a 4-bit biphase-mark preamble (B, M, or W) aligns blocks and specifies channel identity. In DisplayPort, these preambles are discarded to save bandwidth; the packet header (HB1) and packet position explicitly define channel allocation, block start flags, and sample validity.

Lane Mapping and Distribution

Once formatted, the SDP bytes are distributed round-robin across all active Main Link lanes (1, 2, or 4 lanes):

  • Single-Lane Configuration: The entire packet sequence—SS, Header, 32-byte Payload, and SE—is sent serially across Lane 0.
  • Two-Lane Configuration: The packet is interleaved byte-by-byte across Lane 0 and Lane 1.
  • Four-Lane Configuration: The packet is interleaved four bytes at a time across Lanes 0 through 3.

Each sub-packet is protected by an independent parity check (ECC) appended to the data stream, ensuring that transmission errors over high-speed links can be detected and corrected before processing by the audio sink.

Audio Clock Regeneration via Timestamp Packets

Because the audio sample clock is asynchronous to the DisplayPort link symbol clock, the receiver cannot rely solely on the arrival rate of ASPs to drive its digital-to-analog converters. DisplayPort solves this by transmitting Audio Timestamp Packets (ATPs) alongside ASPs during blanking intervals.

The ATP encapsulates two mathematical values:

  • \(M_{aud}\) (Audio Multiplier): A counter tracking the relationship between the audio master clock and the link rate.
  • \(N_{aud}\) (Link Divider): A fixed timebase parameter.

The sink receives the ATP and applies a Phase-Locked Loop (PLL) using the formula:

\[f_{audio\_mclk} = f_{link} \times \frac{M_{aud}}{N_{aud}}\]

This architecture enables the receiver to reconstruct the exact original audio clock, synchronize it with incoming Audio Stream Packets, unpack the IEC 60958 samples from their sub-packets, and deliver jitter-free audio playback aligned with the video stream.