[alsa-devel] Nvidia HDMI and four codecs

[David Henningsson]

On 2011-02-01 17:36, Stephen Warren wrote:
> David Henningsson wrote at Tuesday, February 01, 2011 1:10 AM:
>> I've seen a few Nvidia HDMI's recently which have four HDMI codecs
>> connected to the same HDA controller.
>
> This is the case for any NVIDIA GPU that supports HDA, and also our most
> recent chipset.
>
>> The problem is that we don't know
>> which one(s) of these four that is the real one. So people will have to
>> try devices "hdmi:Nvidia,0", "hdmi:Nvidia,1", "hdmi:Nvidia,2" and
>> "hdmi:Nvidia,3" to figure out which one is the right one. (And by
>> empirical testing we know that it isn't always the first one.)
>
> /proc/asound/card<n>/eld* will tell you which one to use; the ELD file
> numbering should match the hdmi: device numbering.
>
> eld 0,1,2,3 also match hw:$card:$device with device=3,7,8,9.
>
> I do have an audio document that's aimed at technical end-users to explain
> all of this. However, I haven't quite finished it, and issues with the
> publication mechanism have stopped me publishing it so far.
>
>> Thinking PulseAudio and/or "Just Works", this is not good enough, so is
>> there a way to know beforehand which one of these four that is actually
>> physically connected?
>
> I don't believe it's possible to determine which of the codecs are physically
> connected to actual connectors on the graphics board. This would be a static
> facet of the board design.

Ok, thanks for confirming.

As you might have seen, for Intel HDMI I made a patch that makes it act 
upon the pin config default register. I'd love it if things could work 
out the same way for Nvidia HDMI. I don't know enough about the BIOS/HW 
side of things to know for sure, but I guess this will be something up 
to whoever makes the board (e g Asus) to set inside the GPU somehow.

Failing that, we could try hiding things in the driver by quirking, 
either at the codec level or at the pin complex level.

> Beyond that, the ELD files will indicate which codecs/pins are routed to a
> connector with an audio-capable display attached and that X is actually
> sending a signal to. This can dynamically change as the X server is
> reconfigured, either when X restarts, or dynamically through our management
> protocol or application.
>
>> I'd love BIOS to provide a good codec probe mask, a pin config default,
>> or something similar, but given a codec-proc I can't see any difference
>> between the real ones and the unconnected ones, so I don't know how to
>> fix up the driver without hardcoding/quirking every one of them. Any
>> hints?
>
> ALSA now exposes a logical device (hdmi:Nvidia,n) for each pin complex[1]
> (equivalently each codec since there's a 1:1 mapping in our GPUs right now).
> However, PulseAudio still only offers the user the first of these devices,
> thus causing users to resort to probe masks to select which ALSA device they
> wish to use.
>
> If PulseAudio were to offer all HDMI devices in its UI, at least the user
> Could configure their system using the regular GUI tools. I did suggest this
> on the PulseAudio list, and I think the maintainers agreed this would be a
> good idea in principle. However, I haven't taken the time to drive this.
>
> http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07433.html

Thanks, reading that thread made a few things clearer.

As for PulseAudio, showing four HDMI devices is quite simple [1] but I 
still think it would be a little confusing to show four devices to 
choose from and would wish for something more intuitive.

> [1] Concentrating abstractions on pin complexes rather than codecs will
> ensure ALSA etc. are more ready for other codec/converter/pin
> combinations that may be seen on other or future GPUs.

I agree.

So let's sum up the options here:

1) Board manufacturer sets a codec probe mask.

2) Board manufacturer sets pin config default register. This might 
require some support in the driver as well.

1) and 2) won't work for existing boards and I don't know how difficult 
it would be to persuade the board manufacturers to do it for future boards.

3) Quirking in the driver - codec probe mask

This was my primary option until yesterday, when I saw a machine which 
had the same PCI SSID for both the primary HDA controller and the Nvidia 
HDA controller.

4) Quirking in the driver - pin config default register. Will need some 
work in the driver, but I guess it's doable.

3) and 4) gives us a lot of quirking to do.

5) Show all four devices in PulseAudio. Simple, but confusing for the user.

6) Proper jack detection in PulseAudio, which might be based on ELD 
information. This is what would need the most work to do, and things 
will still be confusing for people not using PulseAudio. It might be the 
long path to go anyway, as it would enable features such as auto-moving 
to HDMI when HDMI is plugged in, etc.

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

[1] I haven't tested it, but I guess the following addition to 
/usr/shared/pulseaudio/alsa-mixer/profile-sets/default.conf should do it:

[Mapping hdmi-stereo-extra1]
description = HDMI out extra 1
device-strings = hdmi:%f,1
channel-map = left,right
priority = 2
direction = output

[Mapping hdmi-stereo-extra2]
description = HDMI out extra 2
device-strings = hdmi:%f,2
channel-map = left,right
priority = 2
direction = output

[Mapping hdmi-stereo-extra3]
description = HDMI out extra 3
device-strings = hdmi:%f,3
channel-map = left,right
priority = 2
direction = output