[alsa-devel] Nvidia HDMI and four codecs

[Stephen Warren]

David Henningsson wrote at Wednesday, February 02, 2011 1:04 AM:
> 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.
> >> ...
> >> The problem is that we don't know which one(s) of these four that
> >> is the real one.
> >> ...

(oh, and note that there can be multiple displays active, and hence there
can be more than one "real one").

> > 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.
> ...
> 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 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
> > ...
> > If PulseAudio were to offer all HDMI devices in its UI, at least the
> > user could configure their system using the regular GUI tools.
> > ...
> > 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.

I'm not sure if that will work.

Note: My observations are based on adding the following to
/etc/pulse/default.pa:

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

With the above, at least during startup (and perhaps long-term during
operation), PulseAudio opens all the devices at once. This exceeds the
maximum number of streams our audio controller can support (2), and hence
the load-module fails, and hence the PulseAudio daemon fails to start.

Perhaps the mechanism you presented avoids that?

If you know which specific subset you want, adding fewer of those entries
to the file does work, and can be an alternative to a probe mask.

> So let's sum up the options here:
> 
> 1) Board manufacturer sets a codec probe mask.

I'm not sure how they'd do that, since the probe mask is a Linux-specific
kernel command-line option.

> 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.

Yes, this isn't possible with any current boards.

However, for some future designs, it sounds like we may be setting the
pin config default register to indicate which pin complexes are actually
connected to a physical connector on the board.
 
> 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.

The 3D/VGA controller and the HD-Audio controller will always be different
PCI functions (same domain/bus/device, different function address), and
appropriately marked as either a 3D or audio controller. Perhaps that can
help apply any quirk to the appropriate device/driver.

In practice for all the GPUs I've seen the 3D controller is function 0 and
the HD-audio controller is function 1. However, it would be unwise to
assume those specific numbers will apply in all cases.

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

This is probably better than quirking a probe_mask; it'd be more similar to
the case where this register was already filled in by the HW/BIOS.

> 3) and 4) gives us a lot of quirking to do.
> 
> 5) Show all four devices in PulseAudio. Simple, but confusing for the
> user.

And there is the issue I mentioned above to work out.

> 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

-- 
nvpublic