Jack detection on HDA vs SoC

Jack detection on HDA vs SoC

[Dylan Reid]

under hda I see: new, control-based jack notification, and
auto-switching of the output/input done in the driver.
under soc it is: /dev/input used for jack notification, with the
switching _not_ done in the driver.

Is there a plan for the soc code to use the control-based method?
Is there a consensus on whether new drivers should auto-switch or not?

Thanks,

Dylan

Re: Jack detection on HDA vs SoC

[Raymond Yau]

2012/2/4, Dylan Reid <dgreid@chromium.org>:
> under hda I see: new, control-based jack notification, and
> auto-switching of the output/input done in the driver.
> under soc it is: /dev/input used for jack notification, with the
> switching _not_ done in the driver.
>
> Is there a plan for the soc code to use the control-based method?
> Is there a consensus on whether new drivers should auto-switch or not?
>

Is there any solution for those combo jack of lenovo t400 and ideapad s200 ?

http://forums.lenovo.com/t5/T400-T500-and-newer-T-series/Audio-combo-jack-vs-headphone-earphone-with-mic-and-speaker/ta-p/240186

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5272

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5523

Re: Jack detection on HDA vs SoC

[Mark Brown]

On Fri, Feb 03, 2012 at 06:01:41PM -0800, Dylan Reid wrote:

You're more likely to get responses to mails if you CC maintainers.

> Is there a plan for the soc code to use the control-based method?

Not exactly.  I'm expecting that the new interface will be integrated
into the generic ALSA jack support rather than done as a custom thing in
the HDA drivers which will mean that anything supporting accessory
detect will get support, including ASoC.  This stuff should really be
handled in the core rather than in individual drivers, there's also
extcon which we'll need to integrate with.

> Is there a consensus on whether new drivers should auto-switch or not?

For embedded systems they definitely should not, it's frequently
inappropriate (the most common case is things like ringtones which many
userspaces think should always play to speaker so people can hear them
even if they have removed their headphones).  I think the consensus was
to move the PC audio to supporting runtime switching between the two
modes so that if PulseAudio or whatever userspace sound manager is there
wants to it can take control and do the switching for cases like the
above.

Re: Jack detection on HDA vs SoC

[Mark Brown]

On Sat, Feb 04, 2012 at 01:20:29PM +0000, Mark Brown wrote:
> On Fri, Feb 03, 2012 at 06:01:41PM -0800, Dylan Reid wrote:

> > Is there a plan for the soc code to use the control-based method?

> Not exactly.  I'm expecting that the new interface will be integrated
> into the generic ALSA jack support rather than done as a custom thing in
> the HDA drivers which will mean that anything supporting accessory
> detect will get support, including ASoC.  This stuff should really be
> handled in the core rather than in individual drivers, there's also
> extcon which we'll need to integrate with.

BTW, the core code I'm talking about is that in sound/core/jack.c but I
just noticed we also acquired a sound/core/ctljack.c.

Takashi, we really need to sort this stuff out - it's all getting very
confusing.  We've got two different bits of code with very similar
interfaces on the driver side but totally different application layer
interfaces.  From a driver point of view it's not great to have to tell
the core the same thing twice and from an application point of view we
don't have any consistency.

Looking at the code I don't understand why ctljack is done separately to
the rest of the accessory detection - surely we should just have the
snd_jack code create a control for each thing that can be reported?  I
can't immediately see a problem with just putting a "Headphone Jack" or
whatever the naming convention is for these controls on the end of the
name that we were given for the base jack (probably support that being
empty).

Re: Jack detection on HDA vs SoC

[Dylan Reid]

On Sat, Feb 4, 2012 at 5:20 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Feb 03, 2012 at 06:01:41PM -0800, Dylan Reid wrote:
>
> You're more likely to get responses to mails if you CC maintainers.
>
>> Is there a plan for the soc code to use the control-based method?
>
> Not exactly.  I'm expecting that the new interface will be integrated
> into the generic ALSA jack support rather than done as a custom thing in
> the HDA drivers which will mean that anything supporting accessory
> detect will get support, including ASoC.  This stuff should really be
> handled in the core rather than in individual drivers, there's also
> extcon which we'll need to integrate with.
>
>> Is there a consensus on whether new drivers should auto-switch or not?
>
> For embedded systems they definitely should not, it's frequently
> inappropriate (the most common case is things like ringtones which many
> userspaces think should always play to speaker so people can hear them
> even if they have removed their headphones).  I think the consensus was
> to move the PC audio to supporting runtime switching between the two
> modes so that if PulseAudio or whatever userspace sound manager is there
> wants to it can take control and do the switching for cases like the
> above.

Thanks for the responses Mark. A control that can disable auto switching
sounds like a good solution to me.  Certainly better than checking for x86 or
arm.  I see a couple of drivers already doing this, so I can follow their lead.

Re: Jack detection on HDA vs SoC

[Takashi Iwai]

At Sat, 4 Feb 2012 14:02:09 +0000,
Mark Brown wrote:
> 
> On Sat, Feb 04, 2012 at 01:20:29PM +0000, Mark Brown wrote:
> > On Fri, Feb 03, 2012 at 06:01:41PM -0800, Dylan Reid wrote:
> 
> > > Is there a plan for the soc code to use the control-based method?
> 
> > Not exactly.  I'm expecting that the new interface will be integrated
> > into the generic ALSA jack support rather than done as a custom thing in
> > the HDA drivers which will mean that anything supporting accessory
> > detect will get support, including ASoC.  This stuff should really be
> > handled in the core rather than in individual drivers, there's also
> > extcon which we'll need to integrate with.
> 
> BTW, the core code I'm talking about is that in sound/core/jack.c but I
> just noticed we also acquired a sound/core/ctljack.c.
> 
> Takashi, we really need to sort this stuff out - it's all getting very
> confusing.  We've got two different bits of code with very similar
> interfaces on the driver side but totally different application layer
> interfaces.  From a driver point of view it's not great to have to tell
> the core the same thing twice and from an application point of view we
> don't have any consistency.

Yep, absolutely.

> Looking at the code I don't understand why ctljack is done separately to
> the rest of the accessory detection - surely we should just have the
> snd_jack code create a control for each thing that can be reported?  I
> can't immediately see a problem with just putting a "Headphone Jack" or
> whatever the naming convention is for these controls on the end of the
> name that we were given for the base jack (probably support that being
> empty).

The simple answer is not to break the things right now :)

In the current release, I left ctljack.c as is before the integration
with jack.c simply because of different use-cases I faced: the
input-jack provides the multiple switches for a single jack while the
current ctljack.c provides only a boolean.  Although the ctljack can
provide an enum instead of a boolean for representing a similar model,
I wanted to get the global overlook and a consensus at first.

Meanwhile, the boolean implementation is enough for most of PC
(especially HD-audio) stuff and the ctljack implementation was
demanded.  Thus I decided to merge the branch for 3.2.

Definitely the integration work is necessary and foreseen.  The
biggest problem my workload for other tasks.


thanks,

Takashi

Re: Jack detection on HDA vs SoC

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1427 bytes --]

On Mon, Feb 06, 2012 at 10:48:12AM +0100, Takashi Iwai wrote:

> In the current release, I left ctljack.c as is before the integration
> with jack.c simply because of different use-cases I faced: the
> input-jack provides the multiple switches for a single jack while the
> current ctljack.c provides only a boolean.  Although the ctljack can
> provide an enum instead of a boolean for representing a similar model,
> I wanted to get the global overlook and a consensus at first.

That's not the case with the standard jack stuff at all - it's not using
any enumerations.  Everything that's grouped together is bitfields, it's
just a set of booleans all the way up to userspace.

> Meanwhile, the boolean implementation is enough for most of PC
> (especially HD-audio) stuff and the ctljack implementation was
> demanded.  Thus I decided to merge the branch for 3.2.

So are they just booleans, and is there a naming standard for the
controls?  I've never seen any clear description of the semantics
and I'd been assuming from the fact that all this had been done
outside the standard infrastructure that there was some deep HDA
specificness in the current somewhere but it's not sounding that
way.

> Definitely the integration work is necessary and foreseen.  The
> biggest problem my workload for other tasks.

TBH it looks like it'd have been less work to start off in the core -
all the hooks were already in the drivers.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]