[alsa-devel] ALSA: hda: hdmi: Hint matching between input devices and pcm devices
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in.
This patch adds a name hint that indicates which PCM device is connected to which pin.
To do that, the jack creation has been deferred to build_controls, i e, after the PCM devices have been created.
Would be great to have Stephen look through this patch quickly before it's committed.
David Henningsson wrote at Tuesday, August 23, 2011 9:12 AM:
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in.
This patch adds a name hint that indicates which PCM device is connected to which pin.
To do that, the jack creation has been deferred to build_controls, i e, after the PCM devices have been created.
Would be great to have Stephen look through this patch quickly before it's committed.
Structurally, I think this looks OK. The only question I have is the string format:
"HDMI/DP (pcm %d)", pcmdev
* Is there a 1:1 mapping between the internal pcmdev numbers and what alsa-lib presents to clients? Thinking about ALSA device numbering, it's like "hw:1,3", so includes the card number too; should that be in the string?
* Would it be better to make the string completely generic - i.e. not include "HDMI/DP", but rather something like "ALSA PCM %d", or even "ALSA PCM hw:%d,%d" so that the same format could be used for non-HDMI/ DP PCMs in the future?
On 2011-08-23 17:51, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 9:12 AM:
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in.
This patch adds a name hint that indicates which PCM device is connected to which pin.
To do that, the jack creation has been deferred to build_controls, i e, after the PCM devices have been created.
Would be great to have Stephen look through this patch quickly before it's committed.
Thanks for the review!
Structurally, I think this looks OK. The only question I have is the string format:
"HDMI/DP (pcm %d)", pcmdev
- Is there a 1:1 mapping between the internal pcmdev numbers and what
alsa-lib presents to clients?
That's very much up to the configuration in alsa-lib, but I would say that alsa-lib in general does that, and especially for HDA.
Thinking about ALSA device numbering, it's like "hw:1,3", so includes the card number too; should that be in the string?
The matchup against the card can be done both in sysfs, and using the card name, which is later prefixed to that string. The end result would be something like "HDA NVidia HDMI/DP (pcm 3)"
It's possible though, and somewhat simpler than matching against sysfs to add the card number as well.
- Would it be better to make the string completely generic - i.e. not
include "HDMI/DP", but rather something like "ALSA PCM %d", or even "ALSA PCM hw:%d,%d" so that the same format could be used for non-HDMI/ DP PCMs in the future?
That would probably be bad, as there would be no way to distinguish between e g "Headphone" and "Headphone 2". This is a HDMI specific problem in general, as all analog outputs and inputs are at ,0 and SPDIF at ,1. (Although there might be exceptions, the "Independent HP" thing of the VIA drivers come to mind.)
Up to now, I believe the string in the name has been pretty arbitrarily. E g, I have "Headphone" on one machine and "HP Out" on another. Should we try to establish a format where various parameters can be added, it might be good to try something like ",name=value". Should we add card as well, the result would be e g: "HDA NVidia HDMI/DP,card=2,pcm=3"
David Henningsson wrote at Tuesday, August 23, 2011 10:54 PM:
On 2011-08-23 17:51, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 9:12 AM:
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in.
This patch adds a name hint that indicates which PCM device is connected to which pin.
To do that, the jack creation has been deferred to build_controls, i e, after the PCM devices have been created.
Would be great to have Stephen look through this patch quickly before it's committed.
Thanks for the review!
Structurally, I think this looks OK. The only question I have is the string format:
"HDMI/DP (pcm %d)", pcmdev
- Is there a 1:1 mapping between the internal pcmdev numbers and what
alsa-lib presents to clients?
That's very much up to the configuration in alsa-lib, but I would say that alsa-lib in general does that, and especially for HDA.
Thinking about ALSA device numbering, it's like "hw:1,3", so includes the card number too; should that be in the string?
The matchup against the card can be done both in sysfs, and using the card name, which is later prefixed to that string. The end result would be something like "HDA NVidia HDMI/DP (pcm 3)"
OK, so if the string that user-space sees already has the card name, that's probably enough in practice, although it still seems a little free-form.
One issue with the above string: There's no delimiter that user-space can use to extract just the card name from the whole string. Perhaps add a ":" at the start so there's a delimiter?
"HDA NVidia: HDMI/DP (pcm 3)" "HDA NVidia: pcm 3"
?
It's possible though, and somewhat simpler than matching against sysfs to add the card number as well.
- Would it be better to make the string completely generic - i.e. not
include "HDMI/DP", but rather something like "ALSA PCM %d", or even "ALSA PCM hw:%d,%d" so that the same format could be used for non-HDMI/ DP PCMs in the future?
That would probably be bad, as there would be no way to distinguish between e g "Headphone" and "Headphone 2".
Are those two different analog outputs from the same PCM device?
If so, I don't see a problem with having both those jack's input devices reporting the same PCM name; user-space will just see 2 matches and know that the PCM device is useful if either is plugged in.
If not, I'm afraid I don't have enough context to understand your comment.
This is a HDMI specific problem in general, as all analog outputs and inputs are at ,0 and SPDIF at ,1. (Although there might be exceptions, the "Independent HP" thing of the VIA drivers come to mind.)
Hmm. I don't see it as HDMI specific. If there's a random input device today that represents the analog output's jack detection, how does user- space know the input device is for analog (sub-device 0) at all? Isn't the exact same issue present for any kind of output; I don't how the ,0/,1/,3 numbering affects this. Sorry!
Up to now, I believe the string in the name has been pretty arbitrarily. E g, I have "Headphone" on one machine and "HP Out" on another. Should we try to establish a format where various parameters can be added, it might be good to try something like ",name=value". Should we add card as well, the result would be e g: "HDA NVidia HDMI/DP,card=2,pcm=3"
That sounds pretty sane to me.
On 08/24/2011 11:21 PM, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 10:54 PM:
On 2011-08-23 17:51, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 9:12 AM:
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in.
This patch adds a name hint that indicates which PCM device is connected to which pin.
To do that, the jack creation has been deferred to build_controls, i e, after the PCM devices have been created.
Would be great to have Stephen look through this patch quickly before it's committed.
Thanks for the review!
Structurally, I think this looks OK. The only question I have is the string format:
"HDMI/DP (pcm %d)", pcmdev
- Is there a 1:1 mapping between the internal pcmdev numbers and what
alsa-lib presents to clients?
That's very much up to the configuration in alsa-lib, but I would say that alsa-lib in general does that, and especially for HDA.
Thinking about ALSA device numbering, it's like "hw:1,3", so includes the card number too; should that be in the string?
The matchup against the card can be done both in sysfs, and using the card name, which is later prefixed to that string. The end result would be something like "HDA NVidia HDMI/DP (pcm 3)"
OK, so if the string that user-space sees already has the card name, that's probably enough in practice, although it still seems a little free-form.
One issue with the above string: There's no delimiter that user-space can use to extract just the card name from the whole string. Perhaps add a ":" at the start so there's a delimiter?
Or a ","
"HDA NVidia: HDMI/DP (pcm 3)" "HDA NVidia: pcm 3"
?
It's possible though, and somewhat simpler than matching against sysfs to add the card number as well.
- Would it be better to make the string completely generic - i.e. not
include "HDMI/DP", but rather something like "ALSA PCM %d", or even "ALSA PCM hw:%d,%d" so that the same format could be used for non-HDMI/ DP PCMs in the future?
That would probably be bad, as there would be no way to distinguish between e g "Headphone" and "Headphone 2".
Are those two different analog outputs from the same PCM device?
Yes.
If so, I don't see a problem with having both those jack's input devices reporting the same PCM name; user-space will just see 2 matches and know that the PCM device is useful if either is plugged in.
The problem is not that they have the same name, the problem is with removing "HDMI/DP", or in the analog case "Headphones" and "Headphones 2". This is used to determine which ALSA volume controls one should control when the user wants to change volume. (The PCM device is usually useful regardless, e g with internal speakers which don't have a jack.)
If not, I'm afraid I don't have enough context to understand your comment.
This is a HDMI specific problem in general, as all analog outputs and inputs are at ,0 and SPDIF at ,1. (Although there might be exceptions, the "Independent HP" thing of the VIA drivers come to mind.)
Hmm. I don't see it as HDMI specific. If there's a random input device today that represents the analog output's jack detection, how does user- space know the input device is for analog (sub-device 0) at all? Isn't the exact same issue present for any kind of output; I don't how the ,0/,1/,3 numbering affects this. Sorry!
As for the actual numbering, this is hardcoded in hda_codec.c:get_empty_pcm_device().
The jack input devices solve two different problems for HDMI and analog:
For HDMI, my problem is that I don't know which PCM device to send the output to (because there are four). The jack input device, with the patch, fixes that problem.
For Analog output, my problem is that I don't know which volume controls are affecting the current output path. If the Headphone is plugged in, this might be "Master" and "Headphone" whereas if it is unplugged, it might be "Master" and "Speaker" instead. In theory, analog outputs could show up at both devices 0,2,4 and 5, but in practice, all of them always [1] show up at PCM device 0.
Up to now, I believe the string in the name has been pretty arbitrarily. E g, I have "Headphone" on one machine and "HP Out" on another. Should we try to establish a format where various parameters can be added, it might be good to try something like ",name=value". Should we add card as well, the result would be e g: "HDA NVidia HDMI/DP,card=2,pcm=3"
That sounds pretty sane to me.
Ok, I'm attaching a patch where the only difference is that the format has changed according to the ,name=value syntax.
David Henningsson wrote at Thursday, August 25, 2011 1:14 AM:
On 08/24/2011 11:21 PM, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 10:54 PM:
On 2011-08-23 17:51, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 9:12 AM:
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in.
This patch adds a name hint that indicates which PCM device is connected to which pin.
...
Structurally, I think this looks OK. The only question I have is the string format:
"HDMI/DP (pcm %d)", pcmdev
...
Thinking about ALSA device numbering, it's like "hw:1,3", so includes the card number too; should that be in the string?
The matchup against the card can be done both in sysfs, and using the card name, which is later prefixed to that string. The end result would be something like "HDA NVidia HDMI/DP (pcm 3)"
OK, so if the string that user-space sees already has the card name, that's probably enough in practice, although it still seems a little free-form.
One issue with the above string: There's no delimiter that user-space can use to extract just the card name from the whole string. Perhaps add a ":" at the start so there's a delimiter?
Or a ","
Sure.
"HDA NVidia: HDMI/DP (pcm 3)" "HDA NVidia: pcm 3"
?
It's possible though, and somewhat simpler than matching against sysfs to add the card number as well.
- Would it be better to make the string completely generic - i.e. not
include "HDMI/DP", but rather something like "ALSA PCM %d", or even "ALSA PCM hw:%d,%d" so that the same format could be used for non-HDMI/ DP PCMs in the future?
That would probably be bad, as there would be no way to distinguish between e g "Headphone" and "Headphone 2".
Are those two different analog outputs from the same PCM device?
Yes.
If so, I don't see a problem with having both those jack's input devices reporting the same PCM name; user-space will just see 2 matches and know that the PCM device is useful if either is plugged in.
The problem is not that they have the same name, the problem is with removing "HDMI/DP",
Ah, OK. That makes sense now.
...
The jack input devices solve two different problems for HDMI and analog:
For HDMI, my problem is that I don't know which PCM device to send the output to (because there are four). The jack input device, with the patch, fixes that problem.
For Analog output, my problem is that I don't know which volume controls are affecting the current output path. If the Headphone is plugged in, this might be "Master" and "Headphone" whereas if it is unplugged, it might be "Master" and "Speaker" instead.
In theory, analog outputs could show up at both devices 0,2,4 and 5, but in practice, all of them always [1] show up at PCM device 0.
OK. I think those are just two aspects of the same thing; we always need to know which PCM to use and which controls to use; it's just that in practice sometimes that information is also implied by other means.
So, I don't think a fully general solution hurts.
Up to now, I believe the string in the name has been pretty arbitrarily. E g, I have "Headphone" on one machine and "HP Out" on another. Should we try to establish a format where various parameters can be added, it might be good to try something like ",name=value". Should we add card as well, the result would be e g: "HDA NVidia HDMI/DP,card=2,pcm=3"
That sounds pretty sane to me.
Ok, I'm attaching a patch where the only difference is that the format has changed according to the ,name=value syntax.
Just one question: If the core code prefixes the card name onto this string, the HDMI code will pass in "HDMI/DP,pcm=3" and the core code will join the prefix on the front using a space, yielding "HDA NVidia HDMI/DP,pcm=3". Can we make the joining use a comma so that spaces within fields don't confuse the comma, i.e. "HDA NVidia,HDMI/DP,pcm=3"? Otherwise, does the card name end at the first space, the second, the last? (None of these work in all the cases considering that the second field might be "Headphones 2" with a space in it.
On 2011-08-25 19:41, Stephen Warren wrote:
David Henningsson wrote at Thursday, August 25, 2011 1:14 AM:
On 08/24/2011 11:21 PM, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 10:54 PM:
On 2011-08-23 17:51, Stephen Warren wrote:
David Henningsson wrote at Tuesday, August 23, 2011 9:12 AM:
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in.
This patch adds a name hint that indicates which PCM device is connected to which pin.
...
Structurally, I think this looks OK. The only question I have is the string format:
"HDMI/DP (pcm %d)", pcmdev
...
Thinking about ALSA device numbering, it's like "hw:1,3", so includes the card number too; should that be in the string?
The matchup against the card can be done both in sysfs, and using the card name, which is later prefixed to that string. The end result would be something like "HDA NVidia HDMI/DP (pcm 3)"
OK, so if the string that user-space sees already has the card name, that's probably enough in practice, although it still seems a little free-form.
One issue with the above string: There's no delimiter that user-space can use to extract just the card name from the whole string. Perhaps add a ":" at the start so there's a delimiter?
Or a ","
Sure.
"HDA NVidia: HDMI/DP (pcm 3)" "HDA NVidia: pcm 3"
?
It's possible though, and somewhat simpler than matching against sysfs to add the card number as well.
- Would it be better to make the string completely generic - i.e. not
include "HDMI/DP", but rather something like "ALSA PCM %d", or even "ALSA PCM hw:%d,%d" so that the same format could be used for non-HDMI/ DP PCMs in the future?
That would probably be bad, as there would be no way to distinguish between e g "Headphone" and "Headphone 2".
Are those two different analog outputs from the same PCM device?
Yes.
If so, I don't see a problem with having both those jack's input devices reporting the same PCM name; user-space will just see 2 matches and know that the PCM device is useful if either is plugged in.
The problem is not that they have the same name, the problem is with removing "HDMI/DP",
Ah, OK. That makes sense now.
...
The jack input devices solve two different problems for HDMI and analog:
For HDMI, my problem is that I don't know which PCM device to send the output to (because there are four). The jack input device, with the patch, fixes that problem.
For Analog output, my problem is that I don't know which volume controls are affecting the current output path. If the Headphone is plugged in, this might be "Master" and "Headphone" whereas if it is unplugged, it might be "Master" and "Speaker" instead.
In theory, analog outputs could show up at both devices 0,2,4 and 5, but in practice, all of them always [1] show up at PCM device 0.
OK. I think those are just two aspects of the same thing; we always need to know which PCM to use and which controls to use; it's just that in practice sometimes that information is also implied by other means.
So, I don't think a fully general solution hurts.
Up to now, I believe the string in the name has been pretty arbitrarily. E g, I have "Headphone" on one machine and "HP Out" on another. Should we try to establish a format where various parameters can be added, it might be good to try something like ",name=value". Should we add card as well, the result would be e g: "HDA NVidia HDMI/DP,card=2,pcm=3"
That sounds pretty sane to me.
Ok, I'm attaching a patch where the only difference is that the format has changed according to the ,name=value syntax.
Just one question: If the core code prefixes the card name onto this string, the HDMI code will pass in "HDMI/DP,pcm=3" and the core code will join the prefix on the front using a space, yielding "HDA NVidia HDMI/DP,pcm=3". Can we make the joining use a comma so that spaces within fields don't confuse the comma, i.e. "HDA NVidia,HDMI/DP,pcm=3"? Otherwise, does the card name end at the first space, the second, the last? (None of these work in all the cases considering that the second field might be "Headphones 2" with a space in it.
So, I don't mind a "fully general solution" as long as we during a transitional period allow for a random string (without commas) before the first comma, followed by ",name=value" strings. Value can contain anything except commas, including spaces. So let's work towards ",card=NVidia,type=HDMI/DP,pcm=3" (and maybe add e g location or other stuff from pin default config as needed) but for now it will be okay with "HDA NVidia HDMI/DP,pcm=3".
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in. This patch adds a name hint that indicates which PCM device is connected to which pin.
I've been thinking about this, and there's some additional work needed for the jack-detection to be useful. User-space code will need at some point to rely on the ELD information to know what the HDMI receiver supports, eg to enable/disable passthrough. I hacked a while ago a small patch to make the ELD bytes available in a control (see attached). It seems to work but I wasn't too sure how to expose it. Should we define a convention for the name of this control as well? Or is there a way to link a control to a specify PCM device? Thanks for your feedback, -Pierre
On 08/30/2011 12:14 AM, Pierre-Louis Bossart wrote:
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in. This patch adds a name hint that indicates which PCM device is connected to which pin.
I've been thinking about this, and there's some additional work needed for the jack-detection to be useful. User-space code will need at some point to rely on the ELD information to know what the HDMI receiver supports, eg to enable/disable passthrough.
Meanwhile, at the PulseAudio side, Colin (and Arun?) have made it possible to set capabilities manually in PulseAudio, based on the assumption that the ELD information is often wrong anyway. (?)
I hacked a while ago a small patch to make the ELD bytes available in a control (see attached). It seems to work but I wasn't too sure how to expose it.
I'm assuming that if you have four HDMI pins (or codecs) that will be four "ELD Bytes" controls?
Also, are we sure we want to expose something as driver specific as ELD bytes through that interface, or do we want to do something more generic? (That said, exposing ELD bytes could also be an interim solution while thinking about something more generic.)
Should we define a convention for the name of this control as well?
Note that my patch doesn't change the name of a control but an input device.
Or is there a way to link a control to a specify PCM device?
Unfortunately not - maybe this is something to discuss at Linuxcon Prague?
Pierre-Louis Bossart wrote:
User-space code will need at some point to rely on the ELD information to know what the HDMI receiver supports, eg to enable/disable passthrough. I hacked a while ago a small patch to make the ELD bytes available in a control (see attached). It seems to work but I wasn't too sure how to expose it.
For something device-specific as this, a _BYTES control is the only choice. An alternative would be to have one control for each field in the ELD.
If the driver can detect ELD changes, it must inform userspace that the control has changed. If there is no ELD, the _get callback should return an error, and the control should have been set to unreadable.
Should we define a convention for the name of this control as well?
If software is supposed to be able to find this control for any HDMI device.
Or is there a way to link a control to a specify PCM device?
Yes: set .iface to _PCM instead of _MIXER (this will also prevent 'normal' mixers from showing this control, but a _BYTE control wouldn't be shown anyway), and set .device (and .subdevice, if appropriate) to the PCM device's (sub)device number.
Regards, Clemens
Hi Clemens,
If the driver can detect ELD changes, it must inform userspace that the control has changed. If there is no ELD, the _get callback should return an error, and the control should have been set to unreadable.
Bear with my ignorance of controls, but how does the driver 'inform userspace that the control has changed'?
Or is there a way to link a control to a specify PCM device?
Yes: set .iface to _PCM instead of _MIXER (this will also prevent 'normal' mixers from showing this control, but a _BYTE control wouldn't be shown anyway), and set .device (and .subdevice, if appropriate) to the PCM device's (sub)device number.
This is exactly what I wanted, it makes things simpler. Thanks for the explanation. -Pierre
participants (4)
-
Clemens Ladisch -
David Henningsson -
Pierre-Louis Bossart -
Stephen Warren