pl bossart wrote: > > In practice, NVIDIA GPUs only support sending video signals over at most > > two of these connectors at once, and hence the HD audio controller only > > allows two audio streams to be configured at once. The exact set used can > > be dynamically reconfigured by changing xorg.conf or using NVIDIA's tools > > to manipulate a running X server; similar to xrandr. > > Ok, so now I understand your need to have multiple devices on the same > card. Point taken.
Great! > I am still not clear on the need to expose 4 devices, out of which 2 > are known to be non-functional. > Why not expose to PulseAudio the only two devices that are configured > and functional? > And to go one step further why not present the devices if they are > connected to a receiver? Personally, I dislike that kind of magic, just like "auto input" on monitors etc. However, I appreciate that I'm probably not a typical user, and hiding irrelevant audio outputs would make life easier for users. The information to do this is known inside the audio driver; the video driver causes a Presence Detect (PD) bit, an ELD Valid (ELDV) bit, and ELD data to be passed to the audio HW and driver that could easily implement this. A few things worry me about doing so though: 1) I believe many/most video drivers don't actually pass PD/ELDV bits and ELD data to the hardware yet, so this information isn't actually available. 2) This exposes the SW stack to issues such as corrupt, incorrectly formatted, or incompletely filled out EDIDs in monitors or receivers, since "ELD Valid" is determined by seeing an EDID that contains appropriate audio information. This exposes SW to a new failure mode. Currently, while ALSA does process PD/ELDV/ELD bits and data, if the ELD data is missing for any reason, it falls back to exposing the audio codec HW's capabilities and simply doesn't restrict those based on the monitor's capabilities. Hence, the exposure isn't currently there. Still, this probably isn't a large issue, since I imagine other OSs rely on the same EDID data, so in general it should be correct. 3) During a modeset (screen resolution change, rotation operation, VT-switch, etc.) the video driver must temporarily clear the PD/ELDV bits. This would cause the sink to be removed from pulseaudio, and presumably the streams would get moved to some other sink, or even aborted? When PD/ELDV come back perhaps a couple seconds later, do the streams automatically get sent back where the user previous had them configured to go; to the HDMI monitor? I believe that with a raw ALSA client, no interruption is observed here, since ALSA itself doesn't do anything like closing the device in this case. Overall though, I think other OSs do hide HDMI end-points that are not currently configured or audio capable, so it's probably what users are used to, and in practice doesn't cause significant issues. -- nvpublic _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
