1. Revision History

1.0

  • Initial Release

1.1

  • Fixed a typo.

  • Consistently refer to IDs rather than using the terms number and ID interchangably.

  • Consolidated notes about upgrading ALSA kernel driver.

  • Incorporated feedback from Anssi Hannula:

    • On chipsets without PD/ELD support, ALSA assumes that the monitor supports any and all audio features, not just basic audio.

    • Added notes regarding incorrect textual reporting of the monitor’s list of supported sample rates.

    • Added a patch to the list in Under-Enumeration of Logical Devices

  • Incorporated feedback from Carl Eugen Hoyos:

    • HDMI audio does not work when X is not running and active on the VT; previously, the document stated that it simply may not work.

    • Noted that no monitor is required; an A/V receiver is sufficient.

    • Fixed various issues with probe_mask documentation:

      • probe_mask can’t be specified on the kernel command-line; it only works through modprobe.

      • "0xffffffff" isn’t a valid probe_mask; "-1" must be used to indicate the default probe_mask for a card.

      • Removed recommendation to add 256 to the probe_mask values.

      • Note that CODEC physical IDs are assigned dynamically, and change when using probe_mask. Logical IDs do not change.

    • Note that the ALSA kernel driver can be upgraded pretty easily.

1.2

  • Added item to Issues In Alsa describing the regression in multi-channel audio in recent kernels.

1.3

  • Updated Missing CODEC IDs to describe an additional patch required for the latest FERMI-based GPUs.

1.4

  • Added item to Issues In Alsa describing a problem on some chipsets which causes blank video unless audio is playing.

1.5

  • Reworked CODEC architecture images to take up less space.

  • Added details regarding which chipsets and GPUs use each CODEC architecture.

  • Added basic details of new CODEC architecture introduced in the GeForce 520.

2

  • Added more complete details of new CODEC architecture introduced in the GeForce 520. This entailed rewriting much of the sections describing ALSA device numbering.

  • Changed to single-field numbering scheme.

3
4

  • Added item to Issues In Alsa describing a regression which caused ALSA applications to hang when passing through compressed AC3 streams, and the fix for the regression.

  • Rewrote dead links to commits on the sound-2.6 project on git.kernel.org to refer to the same commit IDs on the sound project.

5

  • Changed "Within a card" to "Within a CODEC" in the description of ALSA pin widget ID descriptions.

6

  • Added section "High-Bandwidth Audio". Updated the email address listed in the document header.

7

  • Documented another kernel patch that caused audio to be routed to the wrong display device on GeForce 520 and newer.

  • Revamped the documentation of which kernels contained which ALSA patches.

    • Validated and fixed the information.

    • Removed the stale and spotty backport information.

    • Added commit subjects, to allow easier research of backports.

    • Simplified the text and layout.

  • Fixed some capitalization.

8

  • Added alternative syntax for /etc/asound.conf's pcm.!default entry.

2. Introduction

This document attempts to describe everything you need to know about configuring audio-over-HDMI on recent NVIDIA GPUs and chipsets. A fair level of detail is provided, in an attempt to fully explain everything, rather than hiding useful details.

For brevity, the phrase GPU below includes both GPUs on standalone graphics cards, and GPUs integrated within chipsets. The phrase GPU specifically covers only NVIDIA GPUs, and never includes GPUs from other manufacturers. In some cases, chipsets and GPUs may be explicitly discussed separately due to differing feature sets.

For brevity, this document discusses HDMI audio. However, everything herein applies equally to Display Port, and in many cases also DVI ports when connected to an HDMI port on the display device.

The references to a "monitor" within this document apply equally to any device capable of receiving an HDMI signal containing an audio signal. In particular, an A/V receiver with an HDMI input may be used to receive the HDMI signal, process just the audio portion of the signal, and either ignore the video portion completely, or pass that video on to a display device.

3. Types of HDMI audio support

3.1. Pre-Azalia

Some older GPUs included a connector to receive S/PDIF audio from a separate sound card, and route that audio over HDMI. This document does not cover such devices at all.

3.2. Azalia

Newer GPUs include a fully-fledged sound card, implemented according to the Intel HD-audio ("Azalia”) specification. This document covers such devices.

4. HD-audio Architecture

The HD-audio specification defines an audio system to consist of a set of objects, each with a specific type. For example, there are:

Controller

What the user sees as the "sound card”. Responsible for sending audio data from the PC’s memory into the audio hardware. Also responsible for providing the driver access to all other objects. A controller may transfer multiple streams of data at once, e.g. to support playing different sounds on different sets of speakers, or different HDMI ports. There is one controller per "sound card”.

CODECs

Responsible for picking a stream(s) from the controller and routing it/them to converter(s). There may be an arbitrary number of CODECs per controller.

Converters

Responsible for formatting a digital PCM audio stream into some other format. For analog audio output, the DAC (Digital to Analog Converter) is a converter. For HDMI audio, the converter packages the audio into a portion of the HDMI signal. There may be an arbitrary number of converters per CODEC.

Pin Widgets

Represents a physical connection to which audio is routed. A pin widget essentially represents a possible connector on the graphics board. There may be an arbitrary number of pin widgets per CODEC. The number of converter and pin widgets may or may not be identical.

The HD-audio specification also defines various data formats and messages, such as:

Presence Detect (PD)

Indicates whether a monitor is attached to a pin widget, or not.

EDID-Like Data (ELD)

A representation of a subset of a monitor’s EDID, which in turn contains information such as supported display modes, supported audio formats, etc. Both EDIDs and ELD represent audio capabilities as SADs; Short Audio Descriptors. Each SAD indicates a format (e.g. PCM, AC-3, …), sample- or bit-rate (e.g. 48KHz) and (for PCM) number of channels (e.g. 2-channel stereo, 8-channel 7.1 surround)

Unsolicited Response (UR)

A message from an HD-audio controller to driver software when some kind of asynchronous event occurs, such PD or ELD information having changed for a particular pin widget.

5. Driver Architecture

The Linux kernel includes an ALSA driver that supports arbitrary HD-audio controllers, including those in GPUs. This driver takes care of virtually all aspects of HDMI audio, and hence this document mainly covers standard ALSA configuration.

When generating an HDMI signal The GPU internally merges the audio data from the HD-audio controller with the video image to generate a complete HDMI signal. This process is transparent to the ALSA driver.

However, a few things are needed from the video driver to make everything work:

  1. The video driver must be able to correctly set up the HDMI video signal. You must be able to connect your monitor and see the Linux X desktop (GNOME, KDE, XFCE, etc.).

  2. The video driver needs to configure the HDMI port to include the audio signal.

  3. The video driver needs to pass monitor presence and ELD information to the HD-audio controller, using a GPU-specific mechanism. The HD-audio controller then passes this information on to the ALSA driver in a standard fashion defined by the HD-audio specification.

Steps 2 and 3 above are implemented by the NVIDIA binary X driver; the nv and nouveau drivers do not support these features.

Both steps 2 and 3 should happen automatically without any need to be explicitly configured or triggered by the end-user, or any operating-system software.

Note that the NVIDIA binary X driver is specifically an X driver. For this reason, steps 2 and 3 (and indeed 1) are only activated when the X server is running, and actively controls the VT. When X is not active, or when the console is VT-switched to a text terminal, HDMI audio will not work.

6. NVIDIA Hardware Architecture

Different generations of GPUs contain different sets of CODECs, converters, and pin widgets. The exact details are given below.

Care must be taken to send the audio stream to the correct ALSA device, so that it is sent to the correct pin widget, and hence correct connectors on the GPU. Using the wrong device may send audio to a black hole, or may send incorrectly configured audio to an active monitor.

GPUs often support fewer concurrently active display devices (monitors) than the number of physical connectors they expose. GPU HD-Audio controllers are typically similarly limited, so that they only support as many concurrent streams (active ALSA devices) as the number of active display devices the GPU itself supports.

Chipsets contain support for both analog audio and HDMI audio. Analog audio and HDMI audio will be exposed as separate CODECs, or sets of CODECs.

Early chipsets (ION an earlier) do not support PD or ELD information. In this case, the ALSA driver assumes that a monitor is always attached, and supports all audio features, including those which your monitor may not actually support. Newer chipsets and all GPUs support PD and ELD.

The exact set of possible hardware configurations is enumerated below.

6.1. Examples

6.1.1. Chipset with 2-channel support, single stream

Chipset supporting stereo and 1 stream

This configuration is used in MCP67 and MCP73.

In the case where multiple HDMI display connectors are present, the audio stream is broadcast to all HDMI connectors at once. A single ALSA device is exposed.

ELD and PD information is not available on these chipsets.

6.1.2. Chipset with 8-channel support, single stream

Chipset supporting stereo and 1 stream

This configuration is used in MCP77, MCP78, MCP79, MCP7A, and ION.

In the case where multiple HDMI display connectors are present, the audio stream is broadcast to all HDMI connectors at once. A single ALSA device is exposed.

ELD and PD information is not available on these chipsets.

In these chipsets, the multiple 2-channel converters are aggregated by the ALSA driver and exposed as a single 8-channel device. Some chipsets support 2, or 8 channels (MCP77). Other chipsets support 2, 6, or 8 channels (MCP79).

6.1.3. Chipset or first GPU configuration with 8-channel support, multi-stream

First GPU configuration

This configuration is used in MCP89, and all GeForce GPUs that contain an HD-audio controller, and not explicitly described below as containing a newer configuration.

Each connector the GPU supports has its own converter and pin-complex. When playing audio, one must choose the ALSA device that corresponds to the connector to which your monitor is attached.

Each 8-channel converter supports 2, 4, 6, or 8-channel streams.

Only 2 displays, and hence two audio streams, may be active at once.

6.1.4. Second GPU configuration with 8-channel support, multi-stream

Second GPU configuration

This configuration was introduced in the GeForce GT 520 and NVS4200M, and will be used by most GPUs released after those.

This configuration is unique in that it contains a single CODEC, and there are fewer converters than pin-complexes. Each connector the GPU supports has its own pin-complex. Each pin-complex contains a mux to select which converter to receive audio from.

Each 8-channel converter supports 2, 4, 6, or 8-channel streams.

There may be as many audio streams concurrently active as there are converters present in the CODEC.

Historically, this configuration was not well supported by the ALSA kernel driver. See GeForce 520 CODEC Architecture Support for details on when this was fixed. This document assumes that you are using a kernel that includes this fix; without it, a few cases will work, but most will not, and hence any attempt to use such hardware without the patch will result in frustration.

7. ALSA Device Numbering

The following sections use these variable names and definitions:

x

ALSA card ID

y

ALSA CODEC ID

z

ALSA pin widget ID

S

ALSA physical stream ID

s

ALSA logical stream ID

ALSA assigns every sound card an ID 0, 1, 2, … Information about card x may be found in directory /proc/asound/cardx.

Within a card, ALSA assigns each CODEC an ID 0, 1, 2, … CODEC IDs are associated with specific pieces of hardware in a static fashion; if ALSA is requested to ignore certain CODECs, the IDs assigned to the remaining CODECs will remain unchanged. Information about CODEC y may be found in /proc/asound/cardx/codec#y. This file describes all converters, pins, and other HD-audio objects attached to that CODEC.

Within a CODEC, ALSA assigns each pin widget an ID 0, 1, 2, … For GPUs which support PD and ELD information, a complete representation of the monitor’s reported capabilties will be available in /proc/asound/cardx/eld#y.z. See Incorrect Reporting of Supported Sample Rates for issues with ELD reporting.

ALSA creates an audio stream for each pin widget. Each stream is assigned both a "physical" ID from a range determined by the pin’s type, and a zero-based "logical" ID.

For analog audio, the first stream’s physical ID is 0. This will be seen on analog sound cards, and the analog CODEC of a chipset. For HDMI audio, streams will receive physical ID 3, 7, 8, or 9, assigned in turn as streams are created. Information about stream S may be found in directory /proc/asound/cardx/pcm#Sp.

Streams will receive logical ID 0, 1, 2, 3, … in turn as streams are created. Logical stream IDs are referred to as s below, and used in ALSA logical device names.

Stream IDs are assigned in turn to pin widgets that ALSA handles. When ALSA is instructed to ignore a CODEC, and hence streams are not created for pin widgets within that CODEC, stream IDs for subsequent CODECs and pins will change.

For hardware that has a multiple CODECs, each with a single pin widget, the following mapping table will apply by default:

CODEC ID (y)

Pin ID (z)

Physical Stream ID (S)

Logical Stream ID (s)

0

0

3

0

1

0

7

1

2

0

8

2

3

0

9

3

For hardware with a single CODEC, each containing a number of pin widgets, the following mapping table will apply:

CODEC ID (y)

Pin ID (z)

Physical Stream ID (S)

Logical Stream ID (s)

0

0

3

0

0

1

7

1

0

2

8

2

0

3

9

3

Recall that a pin widget represents a physical connector on the board. If a monitor is moved between connectors, the IDs used to send audio to that monitor will change.

You will need to know which stream ID is associated with the HDMI monitor that you wish to send sound to. The best way to determine this is to view the content of the eld files mentioned above, and find the file which describes your monitor, then map this to the stream ID by comparing the list of eld and pcmSp files.

On older chipsets which don’t support ELD data, this will not be possible. However, this is not an issue since there will be a single ALSA device in this case.

8. ALSA User-space Physical Device Names

ALSA assigns each stream a variety of physical device names. These device names use stream IDs.

The first such set of names has the format hw:x,S, using the definitions of x and S in the previous section. These devices expose just the raw capabilities of the audio hardware. For example, if the hardware and/or display device support only 2-channel 48KHz stereo audio, then that is all that will be available via this ALSA device.

ALSA also creates a set of names of the format plughw:x.S, again using the definitions of x and S in the previous section. These devices allow software plugins to augment the capabilities of the raw hardware device. These plugins may allow for e.g. automatic sample-rate conversion, or up-/down-mixing to different number of channels.

The command sudo aplay -L will list the exact set of hw: and plughw: device names known to ALSA, e.g.:

hw:CARD=NVidia,DEV=3
   HDA NVidia, NVIDIA HDMI
   Direct hardware device without any conversions
hw:CARD=NVidia,DEV=7
   HDA NVidia, NVIDIA HDMI
   Direct hardware device without any conversions
hw:CARD=NVidia,DEV=8
   HDA NVidia, NVIDIA HDMI
   Direct hardware device without any conversions
hw:CARD=NVidia,DEV=9
   HDA NVidia, NVIDIA HDMI
   Direct hardware device without any conversions
plughw:CARD=NVidia,DEV=3
   HDA NVidia, NVIDIA HDMI
   Hardware device with all software conversions
plughw:CARD=NVidia,DEV=7
   HDA NVidia, NVIDIA HDMI
   Hardware device with all software conversions
plughw:CARD=NVidia,DEV=8
   HDA NVidia, NVIDIA HDMI
   Hardware device with all software conversions
plughw:CARD=NVidia,DEV=9
   HDA NVidia, NVIDIA HDMI
   Hardware device with all software conversions

Notice that this list uses a slightly more verbose device name format; CARD=NVidia is equivalent to numerical card ID 1 or x (see /proc/asound/cards for a mapping of card IDs to names), and Dev=S is equivalent to the numerical stream ID S.

The easiest way to test HDMI audio is to run the speaker-test program using these device names. For example, one of:

For chipsets, which are typically ALSA card 0:

speaker-test -c 2 -r 48000 -D hw:0,3
speaker-test -c 2 -r 48000 -D hw:0,7
speaker-test -c 2 -r 48000 -D hw:0,8
speaker-test -c 2 -r 48000 -D hw:0,9

For GPUs, which are typically ALSA card 1:

speaker-test -c 2 -r 48000 -D hw:1,3
speaker-test -c 2 -r 48000 -D hw:1,7
speaker-test -c 2 -r 48000 -D hw:1,8
speaker-test -c 2 -r 48000 -D hw:1,9

Note that it’s possible for multiple of those commands to work correctly, or partially correctly, depending on various factors. For this reason, it’s more reliable to determine which device IDs to use via the /proc ELD files if available. What’s important is that the previously identified ID works, not whether other IDs also work, completely or partially.

9. ALSA User-space Logical Device Names

Logical device names for HDMI outputs are of the form hdmi:x,s, again using the definitions of x and s given earlier. The command sudo aplay -L will list these too:

hdmi:CARD=NVidia,DEV=0
   HDA NVidia, NVIDIA HDMI
   HDMI Audio Output
hdmi:CARD=NVidia,DEV=1
   HDA NVidia, NVIDIA HDMI
   HDMI Audio Output
hdmi:CARD=NVidia,DEV=2
   HDA NVidia, NVIDIA HDMI
   HDMI Audio Output
hdmi:CARD=NVidia,DEV=3
   HDA NVidia, NVIDIA HDMI
   HDMI Audio Output

Again observe that aplay -L's output uses the slightly more verbose form described previously.

Some older ALSA libraries had a bug that caused only the first logical device ID to work correctly, and/or be listed by aplay -L. Hence, on older distros, there may be fewer hdmi: device IDs than hw: or plughw: device IDs.

10. Issues In ALSA

This section documents various issues that either were fixed in ALSA or that still exist. The fixed issues include both workarounds for GPU behaviour, and fixes or enhancements to ALSA itself.

Each fix describes the mainline kernel or ALSA library version that contains the fix. In some cases, individual distributions may have back-ported some or all of these fixes into earlier kernel versions; check with your distribution vendor.

10.1. Unsolicited Response Formatting

Some earlier GPUs implemented an older version of the HD-audio standard’s Unsolicited Response formatting. The ALSA driver originally only implemented the latest standard. This would cause ALSA to believe that no monitor was attached, or that it was not capable of HDMI audio. This was fixed in the following commit to the ALSA driver:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=38faddb1afdd37218c196ac3db1cb5fbe7fc9c75 "ALSA: hda - Fix pin-detection of Nvidia HDMI"

This patch is included in Linux kernel 2.6.35.

10.2. Missing CODEC IDs

Over time, various new GPUs have been released. Each has a different HD-audio CODEC vendor ID that must be explicitly listed in the ALSA driver for the driver to support the hardware.

Refer to the Vendor Id entry in /proc/asound/cardx/codec#y to determine the CODEC vendor ID of your GPU.

Support for CODEC ID 0x60 was added in the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=d52392b1a80458c0510810789c7db4a39b88022a "ALSA: hda - Add new GPU codec ID to snd-hda"

This patch is included in Linux kernel 3.11-rc2.

Support for CODEC ID 0x51 was added in the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=7ae48b56f8d9c836259bc02f3e2ea4962d6b5d1b "ALSA: hda - Add new GPU codec ID to snd-hda"

This patch is included in Linux kernel 3.6-rc1.

Support for CODEC IDs 0x15 and 0x16 was added in the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=c8900a0fad5ae9f4823451de17ba5dec6653ac74 "ALSA: hda - add new Fermi 5xx codec IDs to snd-hda"

This patch is included in Linux kernel 2.6.38-rc8.

Support for CODEC IDs 0x10, 0x11, 0x12, 0x13, 0x14, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x40, 0x41, 0x42, 0x43, and 0x44 was added in the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=9cf2657d05f9f9e04c3e113d68bf7cef5a942070 "ALSA: hda - patch_nvhdmi.c: Add missing codec IDs, unify names"

This patch is included in Linux 2.6.36-rc1.

10.3. Under-Enumeration of Logical Devices

The ALSA library used to enumerate only a single logical HDMI device per GPU. However, in many cases, there are more. This prevents the creation of an hdmi: device for any but the very first HDMI output of a given sound card, which is often not the device the user needs to use. This was fixed in the following commit to the ALSA library:

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=97d25c0766405453d3c298bd51dd4916121a4f6a "namehint: Evaluate more possibilities for hw devices"

This patch is included in alsa-lib 1.0.24.

The following commits may also be relevant and/or required:

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=0244370be695372a05344ac760d624e0b40ec9ea "namehint: Fix hw device evaluation (missing last device)"

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=c049d48407ff0459ff15e466edeeee6ecff67fcd "namehint: Another fix to properly evaluate hw devices"

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=e6d5dcf1f625984605d362338d71162de45a6c60 "HDA-Intel: present all 4 HDMI outputs instead of just the first one"

10.4. 4/6-Channel Support on Some Older Chipsets

Some older chipsets support both 2-channel and 8-channel operation. By default, ALSA assumes those chipsets can also support 4-channel and 6-channel operation. This is not true for all chipsets. This was fixed in the following commit to the ALSA driver:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=393004b2ea49524ee41a562cae8db67f50f372a5 "ALSA: hda: Disable 4/6 channels on some NVIDIA GPUs."

This patch is included in Linux kernel 2.6.38-rc1.

10.5. 3/5/7-Channel Support

HDMI audio controllers (in general) don’t appear to support 1, 3, 5, or 7-channel audio well. The results may range from error messages to corrupted audio or silence. Historically, the ALSA driver has allowed usage of 1/3/5/7 channels. This was fixed with the following commits:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=ad09fc9d2156f3d37537b34418a6b79309013d33 "ALSA: hda - Suppress the odd number of channels for HDMI"

http://git.kernel.org/?p=Linux/kernel/git/tiwai/sound.git;a=commitdiff;h=4fe2ca14678174d9df254ae3ba2b79bacc19e2ee "ALSA: hda - More coverage for odd-number channels elimination for HDMI"

These patches are included in Linux kernel 2.6.38-rc1.

10.6. Missing Stream ID Cleanup

Each converter receives all audio streams from the controller, and is configured to process a specific stream ID. These stream IDs are dynamically assigned, and a stream ID may be re-used. When stopping audio playback, each converter should be reprogrammed so that it no longer processes that stream ID. This ensures that if a stream ID is re-used, another converter does not mistakenly process that stream; at best, this would be confusing since it would cause audio to be sent to the wrong display device, and at worst the stream could be in a different format, causing corrupt audio to be sent to the wrong display device. This reprogramming was missing from older versions of the ALSA driver. This was fixed with the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=3f50ac6a0ec80a83a1a033fe5004fb319ad72db7 "ALSA: hda - Fix stream and channel-ids codec-bus wide"

This patch is included in Linux 2.6.36-rc3.

10.7. 8-Channel Channel Ordering on Some Older Chipsets

Some earlier chipsets that support 8-channel audio have a channel ordering issue. Consequently, some sounds will come of the wrong speakers. In theory, this could be solved using a plugin within the ALSA library. However, there is currently no way for a driver to indicate to the library that such remapping is necessary.

10.8. Incorrect Reporting of Supported Sample Rates

The /proc eld files and kernel hotplug messages contain a list of sample rates supported by the attached display device. Currently, the list of values is incorrect. For example, for a monitor that supports 32, 44.1, and 48KHz, the lists indicate support for 44.1, 48, and 88.2KHz.

Note that this issue only affects the textual reporting of supported sample rates through syslog and /proc files; programmatic reporting through the ALSA API is correct.

This was fixed with the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=af65cbf296a07c4a52079324fbefdfc9bd2622a3 "ALSA: hdmi: fix printout of SAD sampling rates"

This patch is included in Linux kernel 3.2-rc1.

10.9. Broken Multi-Channel Audio

A recent kernel change accidentally broke multi-channel audio for many users. This is described in detail at:

https://bugzilla.kernel.org/show_bug.cgi?id=28592

This was fixed with the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=11839aed21881d7edd65dd79f22a8eb18426f672 "ALSA: hda - Fix missing CA initialization for HDMI/DP"

This patch is included in Linux kernel 2.6.38-rc5.

10.10. Blank Video Unless Audio Is Playing

Certain chipsets require the audio driver to implement a workaround for audio info-frame generation, and explicitly set the info-frame checksum. The audio driver did not implement the workaround in all cases. In turn, this caused audio info-frames to be transmitted with invalid checksums unless audio was actively playing. Some monitors blank their displays, or fail to detect a signal, in this scenario.

The was fixed with the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=1f348522844bb1f6e7b10d50b9e8aa89a2511b09 "ALSA: hda - HDMI: Fix MCP7x audio infoframe checksums"

This patch is included in Linux kernel 2.6.39-rc3.

10.11. GeForce 520 CODEC Architecture Support

GeForce 520 and newer contain a new CODEC architecture that required an enhancement to the ALSA driver. This was implemented by the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=384a48d71520ca569a63f1e61e51a538bedb16df "ALSA: hda: HDMI: Support codecs with fewer cvts than pins"

This patch is included in Linux kernel 3.1-rc1.

10.12. AC3 Passthrough Hangs

In Linux kernel 3.2-rc1, a regression was introduced which could cause ALSA applications to hang under certain conditions when passing through compressed AC3 streams. The regression was introduced by the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=2ae66c26550cd94b0e2606a9275eb0ab7070ad0e "ALSA: hda: option to enable arbitrary buffer/period sizes"

This patch is included in Linux kernel 3.2-rc1. The regression was fixed by the following commit:

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=52409aa6a0e96337da137c069856298f4dd825a0 "ALSA: hda - Fix buffer-alignment regression with Nvidia HDMI"

This patch is included in Linux kernel 3.3-rc2.

10.13. Audio Routed to the Wrong Monitor

In Linux kernel 3.8-rc1, a regression was introduced which could cause GeForce 520 and newer GPUs to route audio to an unexpected monitor. The selected monitor may not even be connected or be capable of receiving audio, and hence audio may be lost. On system boot, the monitor corresponding to ALSA physical stream ID 3 is likely selected as the audio sink irrespective of which ALSA device is used to play audio. The routing may change following attempts to play multiple audio streams at once. This regression was introduced by the following commit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6169b673618bf0b2518ce413b54925782a603f06 "ALSA: hda - Always turn on pins for HDMI/DP"

This patch is included in Linux kernel 3.8-rc1. The regression was fixed by the following commit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=75fae117a5dbde5ab984fa5c60705758cfbc6433 "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled"

This patch is included in Linux kernel 3.14-rc1.

11. Issues In PulseAudio

11.1. Under-Enumeration of HDMI Devices

PulseAudio only creates a device for the first HDMI output of a given sound card. This means HDMI audio can only be used via PulseAudio if your monitor just happens to be connected to the first active stream on your GPU. This is often not the case. In a mailing list conversation, it was agreed in principle that this needs to be fixed, but no fix is yet in place. See the trouble-shooting section below for methods to work around this issue.

http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07433.html

12. Trouble-shooting

12.1. Upgrading Your ALSA Driver

Older versions of the ALSA driver have various issues that affect audio over HDMI; these are enumerated in Issues In Alsa. Still older versions did not support audio over HDMI at all. If you have an affected kernel, you can either upgrade to a newer kernel, or you can upgrade just the ALSA driver within the kernel to the latest code.

For Ubuntu, there is a repository (PPA) which contains the latest ALSA code; see https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules.

For other distributions, the ALSA driver is relatively easy to build on its own, for many arbitrary kernel versions. See http://alsa-project.org/ for details.

12.2. Verify Your Card Exists

To validate that the ALSA kernel driver sees your card, look at the file /proc/asound/cards. An example is below:

$ cat /proc/asound/cards
0 [Intel          ]: HDA-Intel - HDA Intel
                     HDA Intel at 0xdc600000 irq 52
1 [NVidia         ]: HDA-Intel - HDA NVidia
                     HDA NVidia at 0xd6080000 irq 17

If your system contains an NVIDIA chipset it will most likely show up as entry 0 in this file. If your system contains an NVIDIA GPU (i.e. a discrete graphics card/board), your motherboard’s analog/SPDIF audio controller will typically show up as entry 0, and your GPU as entry 1; that is the case in this example.

If this step fails, some kind of basic driver loading or PCI probing issue has occurred. Check that your sound card shows up in lspci, e.g.:

$ lspci
01:00.0 VGA compatible controller: nVidia Corporation Device 0dd1 (rev a1)
01:00.1 Audio device: nVidia Corporation Device 0be9 (rev a1)

Also, check that the appropriate ALSA kernel modules are loaded, e.g.:

$ sudo modprobe snd_hda_codec_nvhdmi

or more recently:

$ sudo modprobe snd_hda_codec_hdmi

12.3. Verify Your CODEC Is Known/Supported

As mentioned before, the directory /proc/asound/cardx will contain information about a particular card. For example, for a GTX 460M:

$ ls -F /proc/asound/card1
codec#0
codec#1
codec#2
codec#3
eld#0.0
eld#1.0
eld#2.0
eld#3.0
id
pcm3p/
pcm7p/
pcm8p/
pcm9p/

You should validate that the codec#y file(s) exist contain information that looks valid. For example:

$ cat /proc/asound/card1/codec#3
Codec: Nvidia GPU 11 HDMI/DP
Address: 3
Function Id: 0x1
Vendor Id: 0x10de0011
Subsystem Id: 0x10de0101
Revision Id: 0x100100
No Modem Function Group found
Default PCM:
   rates [0x0]:
   bits [0x0]:
   formats [0x0]:
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x04 [Audio Output] wcaps 0x72b1: 8-Channels Digital Stripe CP
 Control: name="IEC958 Playback Con Mask", index=3, device=0
 Control: name="IEC958 Playback Pro Mask", index=3, device=0
 Control: name="IEC958 Playback Default", index=3, device=0
 Control: name="IEC958 Playback Switch", index=3, device=0
 Device: name="NVIDIA HDMI", type="HDMI", device=9
 Converter: stream=6, channel=0
 Digital: Enabled
 Digital category: 0x0
 PCM:
   rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
   bits [0xe]: 16 20 24
   formats [0x5]: PCM AC3
 Unsolicited: tag=00, enabled=0
Node 0x05 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
 Pincap 0x09000094: OUT Detect HBR HDMI DP
 Pin Default 0x18560010: [Jack] Digital Out at Int HDMI
   Conn = Digital, Color = Unknown
   DefAssociation = 0x1, Sequence = 0x0
 Pin-ctls: 0x40: OUT
 Unsolicited: tag=05, enabled=1
 Connection: 1
    0x04

The exact content of this file will vary between generations of GPU. In particular, the number of converters and pin widgets listed may vary, as will their capabilities. Don’t be alarmed if your output doesn’t look identical to the example; the important thing is that the file exists, and lists a reasonable set of rates, bits, and formats.

If you have problems at this step, you may need to update to a newer kernel, or a newer set of ALSA kernel modules, which recognizes your GPU. Upgrading your distribution version may help here. For more details, see Upgrading Your ALSA Driver.

12.4. X Driver Must Be Running

The following steps all assume that X is running using the NVIDIA binary driver, and that your HDMI display is attached to your computer, and displaying your X desktop. HDMI audio is not expected to work if this is not the case.

12.5. Verify Your ELD Is Valid

To validate that the ALSA driver is aware of your monitor, check the eld files. Recall that older chipsets (ION and earlier) don’t support ELD reporting, and hence the ELD files will not exist. In this case, ALSA always assumes that all audio features are available.

For example,

$ cat /proc/asound/card1/eld#3.0
monitor_present     1
eld_valid           1
monitor_name        DELL U2410
connection_type     HDMI
eld_version         [0x2] CEA-861D or below
edid_version        [0x3] CEA-861-B, C or D
manufacture_id      0xac10
product_id          0xf016
port_id             0x40000
support_hdcp        0
support_ai          0
audio_sync_delay    0
speakers            [0x1] FL/FR
sad_count           1
sad0_coding_type    [0x1] LPCM
sad0_channels       2
sad0_rates          [0xe0] 44100 48000 88200
sad0_bits           [0xe0000] 16 20 24

For HDMI audio to work, both monitor_present and eld_valid must be 1. Furthermore, there will typically be evidence of at least some supported audio formats.

See Incorrect Reporting of Supported Sample Rates for issues with ELD reporting.

ALSA’s handling of ELD data has varied slightly over time. The earliest versions simply exposed the raw features (sample rates, number of channels, audio formats) of a sound card’s CODEC to applications. This resulted in applications being able to open a sound device and program a configuration (e.g. 96KHz 8-channel) supported by the sound card , but not by the display device, which perhaps only supported stereo, and at most 48KHz. This could cause no, or corrupted, audio to be heard.

Later versions strictly limited the exposed feature set based on the ELD information. This solved most problems, but was sometimes over-restrictive; some display devices presented no SADs at all in their EDID/ELD. Note that a complete lack of any SAD implies support solely for "basic audio”. This resulted in ALSA informing applications that no features were supported by the audio device. Hence, no audio could be played.

Finally, the current ALSA version limits the features based on ELD, but always allows basic audio features irrespective of the presence or lack of SADs in the EDID.

If you have problems here, double-check that you’re using the NVIDIA binary driver, and not the nv or nouveau drivers; those drivers don’t send the required ELD information to the audio hardware. Verify that your monitor is one of the active display devices driven by X, and that your X desktop (not a text-mode virtual terminal or VT) is visible on your monitor.

Check your X log (/var/log/Xorg.0.log) for any error or warning messages related to HDMI or audio.

Check your kernel log for HDMI hotplug notices, of the form:

HDMI hot plug event: Pin=5 Presence_Detect=0 ELD_Valid=1
HDMI: detected monitor DELL U2410
 at connection type HDMI
HDMI: available speakers: FL/FR
HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 20

(to see these, run sudo dmesg)

These messages are triggered when the NVIDIA binary X driver starts driving a signal to an attached HDMI monitor, which includes writing PD/ELD information into the audio hardware. The writes trigger the audio controller to generate a UR message. When the ALSA driver processes the UR message, it prints the messages to the kernel log.

The important fields are ELD_Valid=1, followed by some list of the audio features your monitor supports. Note that the Presence_Detect=0 portion of the message indicates the raw UR message field, which indicates a change in PD value, not the actual PD value, since most GPUs implement an old verison of the HD-audio specification.

If such kernel messages are not present, or the data is incorrect, or the ELD files don’t show the expected content, you will probably need to contact NVIDIA support for further help. You can either post to the web support forum at http://www.nvnews.net/vbulletin/forumdisplay.php?f=14, or send an email to linux-bugs@nvidia.com. Either way, please first run nvidia-bug-report.sh, and post or attach the resultant file; this file includes information that will help NVIDIA engineers diagnose your issue.

12.6. Ensure All HDMI Outputs Are Unmuted

When testing, all ALSA outputs should be unmuted. Run alsamixer -c x (where x is the card number), use the left/right cursor keys to select each output in turn, and press m so that the output reads OO (rather than MM for muted), and finally press the Esc key to exit.

12.7. Test Playback With ALSA Physical Devices

Once you have identified the ALSA device number of your monitor, test simple playback using speaker-test and then aplay:

$ speaker-test -c 2 -r 48000 -D hw:1,9
$ aplay -D hw:1,9 some_file.wav

As mentioned before, you may get partial success if you use the wrong device IDs here; what’s important is that the correct ones work, not what happens when other IDs are used.

Once you have reached this point, any issues you have, and any further configuration required, are the sole domain of software; everything in the hardware is operating correctly.

12.8. High-Bandwidth Audio

Audio signals that contain a larger number of channels, number of bits per sample, or sample frequency, consume a larger amount of bandwidth within the HDMI signal. The amount of bandwidth available for audio in an HDMI signal is variable, and depends on which video mode is in use. Higher resolution video modes typically use faster pixel clocks, yet have a similar percentage of the signal dedicated to the blanking areas which can carry audio signals, and hence have more available bandwidth to carry audio. Even reduced-blanking modes may have higher available bandwidth for audio than regular modes of some lower resolutions.

For example, stereo 16-bit 48KHz audio can be carried alongside almost any video mode. However, 8-channel 24-bit 192KHz is much more demanding, and requires use of a high pixel clock video mode such as 720p, 1080p, or other modes with similar resolutions.

Verify that stereo 16-bit 48KHz audio works before attempting to use audio signals that require more bandwidth.

12.9. ALSA Default Device

In most current Linux distributions, the default ALSA output device is pulse. This device sends audio to the PulseAudio server, for further distribution. Hence, PulseAudio configuration is what most users care about.

Advanced users who don’t care about PulseAudio can create or edit /etc/asound.conf or ~/.asoundrc in order to change the default ALSA device. The exact syntax depends on your ALSA version For example:

pcm.!default {
        type hw
        card 1
        device 3
}

or:

pcm.!default hdmi:CARD=NVidia,DEV=3

12.10. PulseAudio Default Device

PulseAudio is most often configured using GUI tools. For example, in the GNOME desktop, left-clicking on the speaker icon in the notification area, then clicking "Sound Preferences…” will bring up a GUI tool which will let you select the current output device, amongst other things.

However, on systems that contain more than one possible HDMI output on a given audio card (i.e. most GPUs), PulseAudio only displays a single HDMI output in the list. This is due to the "under-enumeration” problem mentioned earlier. Some people will be lucky, and find this output is the correct one for them (it’s for logical stream ID 0, physical stream ID 3). Others will have to solve this problem in one of two ways:

12.10.1. Adding Extra Outputs To PulseAudio

You can manually add extra outputs to PulseAudio by editing /etc/pulse/default.pa, and adding lines such as ONE of:

load-module module-alsa-sink device=hw:1,7
load-module module-alsa-sink device=hw:1,8
load-module module-alsa-sink device=hw:1,9

PulseAudio will always add a device for ALSA device hw:1,3.

Note that PulseAudio will open all devices it supports at startup. ALSA will only allow as many devices to be opened as the number of audio stream the hardware supports, which is 2 for current GPUs. For this reason, you should not add more than one of these load-module lines to default.pa. Violating this rule will cause the PulseAudio daemon to fail to start.

If your GPU has many HDMI connectors, and you routinely switch your display between them, you may need to edit /etc/default.pa and restart the PulseAudio daemon whenever you switch connectors.

This should then allow you to select the appropriate device using the PulseAudio GUI tools.

12.10.2. probe_mask

The probe_mask ALSA HD-audio module parameter may be used to tell the ALSA kernel driver to ignore some of the CODECs in a GPU. This is useful in the following situations:

  • This method affects ALSA as well PulseAudio.

  • You use two HDMI ports, use PulseAudio, want to use the PulseAudio configuration options mentioned in the previous section, and neither of the two HDMI ports has stream ID 0.

  • You prefer to completely disable hardware you will never use, perhaps so it’s more obvious what you should be using.

  • You prefer kernel command-line options over PulseAudio configuration for whatever reason.

However, this technique will of course only work on hardware the contains multiple CODECs, and not the most recent single-CODEC GPUs.

When using probe_mask, the ID of all CODECs will remain unchanged, even those not in use. However, stream IDs are assigned dynamically, in a contiguous fashion. Hence, stream IDs will change. See the list of /proc/asound/cardx/pcm#Sp to see which stream IDs are valid.

The probe_mask is a bit-mask of the CODECs you wish the kernel to expose. Each CODEC is assigned a mask based on its ID:

CODEC ID

Bitmask

0

1

1

2

2

4

3

8

For each CODEC you want to remain enabled, add the bitmask column together, e.g. to support CODECs with IDs 1 and 3, 2 + 8 == 10 (or in hex, 0x2 + 0x8 = 0xa).

Other online sources, and earlier revisions of this document, indicated that 256 (0x100) should be added to this number. This isn’t a good practice, since adding 256 may force the kernel to probe hardware that isn’t actually present, whereas not adding 256 tells the kernel to restrict its probing to the subset of hardware that you specify; a safer option.

The format of the module parameter is probe_mask=value (e.g. probe_mask=0xa). When multiple sound cards are present in the system, a mask may be specified per card, in the format probe_mask=value_card1,value_card2. A value of -1 may be used to request default handling. So, to set the probe_mask for a discrete NVIDIA GPU and leave a motherboard analog audio controller unaffected, use probe_mask=-1,0xa.

Note: Some sources recommend values such with format 0xfffa, 0xfffffffa, or 0xffffff0a. Thes are all equivalent to 0x10a; bits above bit 8 are ignored, and specifying them only serves to make things more complex than they need be. Specifying bit 8 itself is also no longer recommended as previously described.

For the same reason, you should use a mask of -1 for any cards for which you want default handling, rather than 0xffff, since the latter is again forcing the kernel to probe hardware that may not be present.

To test probe_mask, you can manually remove and reload the appropriate kernel model, for example:

# Custom value
sudo rmmod snd-hda-intel
sudo modprobe snd-hda-intel probe_mask=-1,0xa
# Default
sudo rmmod snd-hda-intel
sudo modprobe snd-hda-intel probe_mask=-1,-1

To make the value permanent, create a modprobe configuration file, for example:

$ cat /etc/modprobe.d/snd-hda-intel.conf
options snd-hda-intel probe_mask=-1,0xa

On older distributions, you may need to place this line in /etc/modprobe.conf instead.

On some distributions, you may need to rebuild your initrd (initial ramdisk) after making such a change; consult with your distribution vendor or help forums for details.

For Ubuntu, run:

sudo update-initramfs -k all -u

13. References

ALSA project

http://www.alsa-project.org/

nvnews.net thread re: ALSA on FERMI GPUs

http://www.nvnews.net/vbulletin/showthread.php?t=154755. In particular, post 7: http://www.nvnews.net/vbulletin/showpost.php?p=2312420&postcount=7

XBMC Wiki Page on HDMI Audio

http://wiki.xbmc.org/?title=HOW-TO_set_up_HDMI_audio_on_nVidia_GeForce_G210,_GT220,_or_GT240

MythTV Wiki Page on HD-Audio Pass-Through

http://www.mythtv.org/wiki/User_Manual:HDAudioPassthrough

Ubuntu ALSA Modules Wiki Page

https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules