[alsa-devel] RFC: Jack-detection control elements on HD-audio
Hi,
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged. But, another big win is that you can read the current pin sense just by reading this element.
I think this is a sort of feature Lennart wanted for PA. Lennart, does it make sense?
The test codes are already in topic/hda-jack branch on sound-unstable GIT tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git topic/hda-jack
Any comments appreciated. This is also intended for 2.6.32, not for 2.6.31 merge, of course :)
thanks,
Takashi
On Fri, 19 Jun 2009, Takashi Iwai wrote:
Hi,
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged. But, another big win is that you can read the current pin sense just by reading this element.
Before definining such extension, I would really see to define standard control names in Documentation/ControlNames.txt file. It seems to me that most new drivers does not follow suggested naming. The document should be reviewed, of course.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Fri, 19 Jun 2009 10:54:00 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 19 Jun 2009, Takashi Iwai wrote:
Hi,
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged. But, another big win is that you can read the current pin sense just by reading this element.
Before definining such extension, I would really see to define standard control names in Documentation/ControlNames.txt file. It seems to me that most new drivers does not follow suggested naming. The document should be reviewed, of course.
That's true. We definitely need a standard naming.
But note that these controls are no mixers but provided as IFACE_CARD, so they won't pollute the mixer abstraction. So, it's rather the question of the user of these controls.
Takashi
On Fri, 19.06.09 10:54, Jaroslav Kysela (perex@perex.cz) wrote:
Heya,
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged. But, another big win is that you can read the current pin sense just by reading this element.
Before definining such extension, I would really see to define standard control names in Documentation/ControlNames.txt file. It seems to me that most new drivers does not follow suggested naming. The document should be reviewed, of course.
Oh yes, please!
I have recently reworked PA to control the mixer a bit more comprehensively, including doing input source selection stuff and suchlike. For that I made a little survey on all current drivers how they name things. Was a bit disappointing, for example for "Input Source"/"Capture Source" we have at least options by these names:
Analog Analog Inputs AOUT Aux AUX Aux0 Aux1 Aux2 Aux3 Aux In AUX IN Cam Mic Digital Mic Digital Mic 1 Digital Mic 2 D-Mic Docking-Station Dock Mic e-Mic E-Mic ExtMic Ext Mic FM Front Mic Front Microphone iMic i-Mic Input1 Input2 Int DMic Internal Mic Internal Microphone IntMic Int Mic Line LineIn Line In Line-In Line/Mic Mic Mic1 Mic2 Mic/Line Microphone Rear Mic TV Tuner Unknown1 Unknown2 Video
Shouldn't be too difficult to agree on standard names for most of these.
I'll post abit more about my findings later.
Lennart
On Fri, Jun 19, 2009 at 10:04:47AM +0200, Takashi Iwai wrote:
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
It'd be nice to keep the input API interface as well - one of the reasons I carried on with the existing input interface was that the existing userspace stuff I found was using the input API in one way or another. In the embedded space it appears to have often been convenient for people to read jack sense from a GPIO as part of a GPIO keyboard they're already using which was part of the reason it was never really joined up with ALSA in the past.
I suspect that which interface is more convenient will depend on what the application responding to the events is doing. For system-wide things that aren't focused on audio being able to use the general input API makes some sense, while for audio-focused applications that are already using ALSA sitting within the ALSA APIs is useful. This sort of system wide thing is probably more common in the embedded space, though HAL/DeviceKit do similar things in the desktop space for other kinds of hardware.
Perhaps rather than superceeding the existing ABI it'd make sense to have something in user space as either a plugin or part of the library which remaps things into a more ALSA framework? I confess I've no idea what sort of work is involved in doing that; it may be simpler to just provide two ABIs.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged.
Including the colours (where reported) is often very helpful for figuring out what's what. The pictures manufacturers seem fond of using for describing the jack functions aren't always models of clarity to the general user.
At Fri, 19 Jun 2009 10:53:22 +0100, Mark Brown wrote:
On Fri, Jun 19, 2009 at 10:04:47AM +0200, Takashi Iwai wrote:
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
It'd be nice to keep the input API interface as well - one of the reasons I carried on with the existing input interface was that the existing userspace stuff I found was using the input API in one way or another. In the embedded space it appears to have often been convenient for people to read jack sense from a GPIO as part of a GPIO keyboard they're already using which was part of the reason it was never really joined up with ALSA in the past.
Don't worry, it's kept as is. The control elements are just additions.
Sorry, my wording was unclear. Let me clarify: the input jack API is there and used as is now. What I meant as "supersedes" is that the code to create and handle the input jack instances in HD-audio driver is generalized to one and used together with the control API.
I suspect that which interface is more convenient will depend on what the application responding to the events is doing. For system-wide things that aren't focused on audio being able to use the general input API makes some sense, while for audio-focused applications that are already using ALSA sitting within the ALSA APIs is useful. This sort of system wide thing is probably more common in the embedded space, though HAL/DeviceKit do similar things in the desktop space for other kinds of hardware.
Right.
Perhaps rather than superceeding the existing ABI it'd make sense to have something in user space as either a plugin or part of the library which remaps things into a more ALSA framework? I confess I've no idea what sort of work is involved in doing that; it may be simpler to just provide two ABIs.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged.
Including the colours (where reported) is often very helpful for figuring out what's what. The pictures manufacturers seem fond of using for describing the jack functions aren't always models of clarity to the general user.
Yes, HD-audio spec gives such information, too.
However, the verbose information like a color doesn't fit into the id string. A better option would be through the additional TLV like dB scale. I just considered but didn't write up yet.
thanks,
Takashi
On Fri, Jun 19, 2009 at 12:08:49PM +0200, Takashi Iwai wrote:
Sorry, my wording was unclear. Let me clarify: the input jack API is there and used as is now. What I meant as "supersedes" is that the code to create and handle the input jack instances in HD-audio driver is generalized to one and used together with the control API.
Ah, OK - in that case it sounds like a great idea. Normally superceding something implies replacing it (so ALSA supercedes OSS).
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged.
Including the colours (where reported) is often very helpful for figuring out what's what. The pictures manufacturers seem fond of using for describing the jack functions aren't always models of clarity to the general user.
Yes, HD-audio spec gives such information, too.
It was HDA that I was thinking about.
However, the verbose information like a color doesn't fit into the id string. A better option would be through the additional TLV like dB scale. I just considered but didn't write up yet.
Yeah, so long as the information is there it doesn't really matter how it gets there.
Takashi, I looked at your code for jack sensing and I am really confused on how these evolutions will be used. It seems to me these additions with the new control apply only to the HDAudio case. Meaning if Lennart modifies PulseAudio to read the jack sensing information from the new control, Lennart's code will not work on embedded platforms which rely on ASoC and plain snd_jack_report / input layer (or any non-HDAudio based solution for that matter), and we don't have a generic way to providing the jack information to PulseAudio. I had a private discussion with Mark where he stated that ASoC would not change, and would automatically benefit from this additional control. That does not seem to be the case. Either I am missing something (not an unlikely scenario, I am light-years from my comfort zone here) or everyone is on a different wavelength. Thanks for your feedback, Cheers - Pierre
On Fri, Jun 19, 2009 at 5:08 AM, Takashi Iwaitiwai@suse.de wrote:
It'd be nice to keep the input API interface as well - one of the reasons I carried on with the existing input interface was that the existing userspace stuff I found was using the input API in one way or another. In the embedded space it appears to have often been convenient for people to read jack sense from a GPIO as part of a GPIO keyboard they're already using which was part of the reason it was never really joined up with ALSA in the past.
Don't worry, it's kept as is. The control elements are just additions.
At Thu, 2 Jul 2009 17:27:52 -0500, pl bossart wrote:
Takashi, I looked at your code for jack sensing and I am really confused on how these evolutions will be used. It seems to me these additions with the new control apply only to the HDAudio case. Meaning if Lennart modifies PulseAudio to read the jack sensing information from the new control, Lennart's code will not work on embedded platforms which rely on ASoC and plain snd_jack_report / input layer (or any non-HDAudio based solution for that matter), and we don't have a generic way to providing the jack information to PulseAudio. I had a private discussion with Mark where he stated that ASoC would not change, and would automatically benefit from this additional control. That does not seem to be the case. Either I am missing something (not an unlikely scenario, I am light-years from my comfort zone here) or everyone is on a different wavelength.
The features I want to implement (for HD-audio, so far) are just using the existing framework. That is, you can implement pretty easily on any drivers that can detect the jacks as well. It's just like adding new mixer elements. Once after other drivers need it, we can move the helper functions to the common layer.
In other words, the jack reporting over control API is generic, in the sense as generic as mixer controls. And, it doesn't conflict with the existing jack input layer.
Takashi
Thanks for your feedback, Cheers
- Pierre
On Fri, Jun 19, 2009 at 5:08 AM, Takashi Iwaitiwai@suse.de wrote:
It'd be nice to keep the input API interface as well - one of the reasons I carried on with the existing input interface was that the existing userspace stuff I found was using the input API in one way or another. In the embedded space it appears to have often been convenient for people to read jack sense from a GPIO as part of a GPIO keyboard they're already using which was part of the reason it was never really joined up with ALSA in the past.
Don't worry, it's kept as is. The control elements are just additions.
On Fri, 19.06.09 10:04, Takashi Iwai (tiwai@suse.de) wrote:
Hi,
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged. But, another big win is that you can read the current pin sense just by reading this element.
I think this is a sort of feature Lennart wanted for PA. Lennart, does it make sense?
Yes. I think it would. Also, if we can use the name of a control to find the jack sensing control for it this would be great. I.e. if we have a control "Headphone" and the Jack sensing control for it would then be called "Headphone Jack" or so, this would be great!
Right now the only way to identify the purpose of a mixer element is by knowing it and going by the name. Would be good if that would be made easy for jack sensing controls.
This also relieves us a bit from the little ugliness of having to manage permissions for those input devices differently from other input devices.
Lennart
At Fri, 19 Jun 2009 14:21:26 +0200, Lennart Poettering wrote:
On Fri, 19.06.09 10:04, Takashi Iwai (tiwai@suse.de) wrote:
Hi,
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged. But, another big win is that you can read the current pin sense just by reading this element.
I think this is a sort of feature Lennart wanted for PA. Lennart, does it make sense?
Yes. I think it would. Also, if we can use the name of a control to find the jack sensing control for it this would be great. I.e. if we have a control "Headphone" and the Jack sensing control for it would then be called "Headphone Jack" or so, this would be great!
Ah, that's a good point. So far, there is no strict connection between them since the jacks are physical while the volume controls are logical. But, they could correlate a bit more with each other. Another TODO.
As posted in another mail, some extra information such as jack location can be stored in the control TLV. So they can be really named as "Headphone Jack".
thanks,
Takashi
participants (5)
-
Jaroslav Kysela -
Lennart Poettering -
Mark Brown -
pl bossart -
Takashi Iwai