RFC: Jack-detection control elements on HD-audio

RFC: Jack-detection control elements on HD-audio

[Takashi Iwai]

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

Re: RFC: Jack-detection control elements on HD-audio

[Jaroslav Kysela]

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.

Re: RFC: Jack-detection control elements on HD-audio

[Takashi Iwai]

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

Re: RFC: Jack-detection control elements on HD-audio

[Mark Brown]

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.

Re: RFC: Jack-detection control elements on HD-audio

[Takashi Iwai]

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

Re: RFC: Jack-detection control elements on HD-audio

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: RFC: Jack-detection control elements on HD-audio

[Takashi Iwai]

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

Re: RFC: Jack-detection control elements on HD-audio

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: RFC: Jack-detection control elements on HD-audio

[Mark Brown]

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.

Re: RFC: Jack-detection control elements on HD-audio

[pl bossart]

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 Iwai<tiwai@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.

Re: RFC: Jack-detection control elements on HD-audio

[Takashi Iwai]

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 Iwai<tiwai@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.
>