[alsa-devel] Jack detection on HDA vs SoC
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
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...
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.
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).
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
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.
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.
participants (4)
-
Dylan Reid -
Mark Brown -
Raymond Yau -
Takashi Iwai