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
