On 2011-05-26 19:45, Stephen Warren wrote:
David Henningsson wrote at Thursday, May 26, 2011 3:52 AM:
On 2011-05-26 08:56, Takashi Iwai wrote:
At Wed, 25 May 2011 11:29:35 -0700, Stephen Warren wrote:
Most cards supported by patch_hdmi.c have the property of a 1:1 mapping or connection between converter widgets and pin widgets. Hence, patch_hdmi.c sets up a PCM for each converter, and occasionally performs some operations on the pin widget as required.
However, some new cards don't have this 1:1 mapping. In particular, the new GeForce GT 520 and many future NVIDIA cards, and at least the Intel Ibex Peak (in my wife's laptop), have more pin widgets than converters, and each pin widget has a mux to select which converter to take the audio from.
For pretty pictures, see the 4th (and 3rd) diagrams at:
ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html#_examples
Wow, nice to see such a good document.
Indeed!
I'd like to discuss how best to handle such cards.
I'd expect to see a PCM device created for each pin widget. This would create a 1:1 mapping between PCM devices and attached monitors and hence ELD data (with the possible exception of DisplayPort 1.2 daisy- chaining; I have no idea yet how that plays into this).
Does this seem like a reasonable approach to everyone?
Sounds reasonable and logical to me. It won't break the older chips, and it will work with new chips.
It makes PulseAudio's life harder, if that is to take into account; in
(I'll use the phrase "unsupported" below to mean the codecs with fewer converters than pins. This is slightly false since they are supported to some extent, but bear with the simple terminology:-)
Certainly, we should take this into account. But, I don't think it actually changes anything for PulseAudio; see my comments below.
the startup phase, PulseAudio usually only tries one of the pcm streams (which is bad here, it'll effectively rule out all ports but the first), if we change to all of the pcm streams, the latter two will fail since the former ones are already opened.
PulseAudio already needs to deal with this.
I stand corrected; I must have thought wrong somehow.
So from a conceptual view, I don't really like the one-pcm-per-pin idea, because it makes HDMI hda and analogue hda more different. (Or are we considering one-pcm-per-pin for the other codecs as well?) We risc fragmenting the driver further, where we should instead try to unify it.
But from a pragmatic view, for this particular problem, it seems your solution might be the simplest way forward.
The supported NVIDIA HDA controllers have 4 codecs, each having 1 converter and 1 pin. Hence, there are 4 PCMs, 1 per codec. PCMs can't be unified/shared/... across codecs. However, our HDA controllers only support 2 streams, because our GPUs only support two active displays at once. Hence, any attempt to open all 4 PCMs at the same time (rather than in serial) will fail on the 3rd PCM.
So, the one-PCM-per-pin model for the new unsupported codecs doesn't introduce any new issue here.
So we're effectively breaking some of the older chips by changing the PCM device from hw:X to hw:X,1 for a specific pin...?
I don't believe the PCM device names would change for existing supported codecs.
If you have one converter and three pins connected to it (I think some intels have this?), then addressing the second and third pin would be a change.
For the unsupported codecs, yes, we'll start to see ${pin_index} be non-zero, and end up with names like hw:0,3.0, hw:0,3.1, and hw:0,3.2. However, even if we made a PCM-per-converter work for those codecs, rather than switching to a PCM-per-pin like I proposed, we'd still end up with those new names, simply due to the existence of multiple converters within the codec.
*If* you want to use the second converter at all, which will only be in the relative rare case of you wanting to use two converters in parallel.
In fact, if there are any codecs that have a 1:1 mapping between converters and pins, yet lump everything into a single codec, we already have those names. I don't know enough about other vendors' codecs to know if this setup existing in practice or not.
So, PulseAudio needs to support hw:x,P.z with z!=0 anyway.
But you're right about this (with your correction about it's hw:x,y in both cases), so maybe it doesn't matter...
Implementing that would probably be just as easy. The difficult part is knowing which pin the user wanted to "assign" the converter to. That's the part that having an explicit PCM-per-pin solves.
In the pcm-per-converter, one would just take the first one that supports audio. For the simplest and thus most common case (only one hdmi monitor connected) then pcm-per-converter would be simpler (just access the ,0 device, no need to figure out which device to use), for the more complex cases, maybe pcm-per-pin is simpler.
Thanks for taking the time to think the proposal; it's always good to get feedback.
Thanks for taking the time to write it. :-)