[pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices

[Stephen Warren]

pl bossart wrote:
> > If I hack /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf to
> > change hdmi-stereo's device-strings value to e.g. "hdmi:%f,0", "hdmi:%f,1",
> > etc., then I can cause pulseaudio to open whichever subdevice I wish. This
> > proves to me that this is simply an enumeration issue and nothing more
> > fundamental.
> 
> I beg to disagree..
> I have done similar work and I think there's something fundamentally
> broken in the ALSA/PulseAudio interaction for HDMI support(See my
> posts on the ALSA mailing list). On my Intel IbexPeak, there's only
> one HDMI device, but it is detected even though there's no cable
> connected. I can play audio on HDMI even if I unplug the cable.
> I would assume this is the same case for your Nvidia system, even if
> you hacked the profile definition, you would end-up with a set of
> detected profiles, but only one may work and only if there's a cable
> connected. That would beat any audio policy/device manager/intelligent
> routing logic.

Sure, but I think my issue is pretty orthogonal to yours.

What I'm talking about is that pulseaudio is incapable of ever sending
audio to anything other than the default device/subdevice within a card,
irrespective of whether a cable is plugged in and signal being transmitted.

What you're talking about is allowing pulseaudio to determine whether a
cable is plugged in and a signal being transmitted, and dynamically
hide/unhide (or enabled/disable) those sinks based on that information.

Incidentally, that information is already available to the ALSA driver; on
HDMI, the "PresenceDetect" and "ELD Valid" bits in /proc/asound/card*/eld*
encode the information pulseaudio would need to use for this.

However, I'm not completely convinced that pulseaudio *should* dynamically
hide/unhide the audio sinks. I suppose in an automatic mode, pulseaudio
should simply send audio to whichever sink makes sense, and an HDMI sink
that's not transmitting a signal perhaps doesn't make sense. However, I
really don't like the idea of not having any kind of manual override which
simply says "I want my audio to come out this HW device that I know I have
no matter what, even if there's some reason it won't work, like no signal
being transmitted"... But again, that discussion is something outside the
scope of this thread.

> For HDMI, I think the right solution is to have some ALSA hot-plug
> event trapped by PulseAudio. Otherwise it's going to be really
> confusing for users. With Nvidia hardware, they would have to manually
> select which profile they want to play on, when they will want to play
> on the device that has a cable attached.
> 
> Along the same lines, there's currently no means to know how many
> channels the receiver supports. We could add HDMI
> stereo/surround40/surround51/surround 71 profiles, but this is the
> least user-friendly solution. Again we do need some hot-plug event to
> set the relevant number of channels for the PulseAudio HDMI sink based
> on ELD/EDID information.

-- 
nvpublic