At Wed, 22 Feb 2012 01:43:44 -0500,

The biggest problem is that PA checks only the first HDMI device.
In that sense, this is no regression in the kernel side, although I
know it's annoying.

If the new two pins can be never used, i.e. physically unreachable,
we may disable these pins by giving the proper default pin-config
values.  Usually it's a job of BIOS.  But if BIOS doesn't do it, user
need to do it manually.

Build your kernel with CONFIG_SND_HDA_HWDEP=y,
CONFIG_SND_HDA_RECONFIG=y, CONFIG_SND_HDA_PATCH_LOADER=y.
I guess most of distro kernels are built with them.
Then create a file containing below in /lib/firmware, such as,
/lib/firmware/ibx-hdmi:

================================================================
[codec]
0x80862804 0x80860101 3
[pincfg]
0x04 0x411111f0
0x06 0x411111f0
================================================================

Now pass this file to "patch" module option for snd-hda-intel.
For example, create a file in /etc/modprobe.d/,
e.g. /etc/modprobe.d/50-hdmi.conf, containing the line

options snd-hda-intel patch="ibx-hdmi"

Then reload the driver or reboot.  This will disable pins 0x04 and
0x06 so that only the pin 0x05 will be used.

Takashi

pulseaudio probably has that device open, hence aplay can't open it
again. To validate this, run the following:

pasuspender bash

Then, run your aplay within that bash. At least aplay should run now,
even if you still can't hear audio; it's possible you don't (or can't)
have anything hooked up to that audio output

There are ways to configure pulseaudio to allow the user to select which
PCM device to use on a given sound card. David Henningsson made this work
for NVIDIA GPUs at least in Ubuntu, and I imagine the same technique
could be applied to Intel devices too.

In the meantime, the WAR that Takashi mentioned in his response sounds
like it'd work very well, albeit it's a bit manual to set up.

It's plausible that isn't connected, or is connected to a graphics port
you simply don't have hooked up to a monitor or audio-capable monitor.

As Takashi mentions, from a kernel perspective, this isn't really a
regression at all, but simply exposing all the features of the HW that
were previously hidden. Without that change, others can't use some HW
usefully at all. Unfortunately, pulseaudio makes some rather simplistic
assumptions about how HW works by default, and can be confused by the
additional features that are exposed.

Sorry this caused problems for you.

--
nvpublic

From a distro perspective, it's a regression that happens to be
bundled with a feature.  Though from a distro perspective working
around this in pulseaudio and making sure even old releases get the
fix might be okay.

I thought that "no regressions" meant that the first sentence and not
the second sentence of the previous paragraph apply from a kernel
perspective.  No?  So I would be happiest if there is some way to
teach the kernel about this quirk until everyone already has had a
fixed pulseaudio for a year or two.

Jonathan

I think the following Ubuntu bug covers the patch:

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/71[..]
See the patch in comment #2.

Hopefully David will chime in on upstreaming status etc.

The following might be interesting; at least some of it will apply to
non-NVIDIA graphics cards:

ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gp[..]

--
nvpublic

There is active work going on in this area. In fact, I just posted a
patch to the PA mailinglist [1]. And yes, we already have it in Ubuntu
11.10 (to probe multiple hdmi devices for Intel and NVidia), and the
main reason it took until now to upstream that patch, was the decision
to switch jack detection method from input devices to kcontrols.

Let me also push for the hda-jack-retask [2] application, which is an
easy-to-use GUI for creating these types of firmware files. I advertised
it here a while ago [3] but it seems to have gone unnoticed.

--
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

[1] http://lists.freedesktop.org/archives/pulseaudio-discuss/201[..]

[2] http://voices.canonical.com/david.henningsson/2011/11/29/tur[..]

[3] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-De[..]

Stephen, could you comment on this? Are we guaranteed a certain board
configuration (i e which pins are physically connected or not) given a
PCI SSID, or anything else that can be used as a key to a quirk table? I
think I've asked you before and that the answer was "no", but my memory
could be failing me.

Even if there is only one HDMI output, it's it not that uncommon,
actually. Many DVI outputs can output HDMI audio as well (when connected
through an HDMI monitor through DVI->HDMI adapter), and DisplayPort also
has audio support.

--
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

Any quirks would definitely have to include the PCI subsystem vendor ID
and subsystem device ID to stand any chance of working; the main dev and
vendor IDs certainly aren't enough.

For NVIDIA GPUs, my expectation is that matching on all 4 IDs would often
provide a unique key that determines which quirks to apply. However, the
subsystem IDs are assigned by OEMs, and I have no idea whether they re-
use the same IDs for different boards sometimes (I believe they shouldn't,
but that doesn't necessarily mean anything). I assume the situation is
identical for Intel graphics chips, but I can't really comment there at
all!

In summary: Our GPUs have a bunch of output port pins, and it's up to the
individual board design which of those to use for which ports. There
should be a 1:1 mapping between the 4-part PCI ID and the set of ports
used and what for, but there's no way to guarantee that's true across all
boards.

Finally, if we did start quirking this, a complete table would end up
being potentially enormous; an entry for every graphics board or mother-
board with integrated graphics ever made...

--
nvpublic

I hope they'll be in PulseAudio 2.0, as they are currently waiting for
review. For next release, see [2], but judging from the PulseAudio 1.0
release process - no, I don't know when this will be ;-)

If you want them to apply to PulseAudio 1.1, you can have a look at [1].
The patches currently posted apply to git head. You'll need all of the
06* patches (as well as Linux 3.3 for the kcontrols).

A more light-weight version could be what I did in Ubuntu 11.04, where
there was no jack detection, but I just exposed all four devices in
PulseAudio and let the user choose manually, like this [4]. (I later
renamed that file from "nvidia.conf" to "extra-hdmi.conf", and added the
same file to be used for Intel chips.)

Certainly, if there is interest from the Debian side to have it.

I would also not mind if it became a part of upstream ALSA, I think it
would make a nice addition to the hda-analyzer, hda-verb etc tool set.

I think the easiest way is just to download the hda-jack-retask
application and build it yourself. Otherwise, [3].

You're welcome.

--
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

[1] http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubu[..]

[2]  http://pulseaudio.org/wiki/ReleasePlanning

[3]  http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio.txt

[4] http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubu[..]

At Sun, 04 Mar 2012 03:43:20 +0100,

It could be indeed helpful to merge it to alsa-tools package.  Feel
free to submit the patches or a git pull request.

hda-analyzer is currently in alsa.git, not in alsa-tools.git, by some
reason.  I guess it'd be no big problem to move it to alsa-tools if
Jaroslav doesn't mind.

hda-verb can be certainly to be merged to alsa-tools.  I'll add it
later.

OTOH, hda-emu doesn't fit to alsa-tools.  It's a no program to be
provided in a pre-compiled form such as a distro package.

thanks,

Takashi