[alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
ricardo.neri at ti.com
Wed Aug 22 03:24:45 CEST 2012
On 08/21/2012 08:16 AM, Mark Brown wrote:
> On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote:
>> On 08/21/2012 02:05 PM, Mark Brown wrote:
>>> - sound/core/ctljack.c which was added later and provides separate
>>> in-kernel and userspace APIs and is currently only used by HDA.
>> This is wrong. PulseAudio uses the new ctljack API. I started out
>> with an implementation which used the input device API
>> (sound/core/jack.c), but since some people did not like this API,
>> the ctljack API was designed and implemented for PA to use, which it
>> does (since PulseAudio 2.0 - the input device API implementation in
>> PulseAudio was never merged upstream).
> ...and the only thing using this API to generate events is HDA which is
> what I was talking about here given that this is a question from a
> driver point of view.
>>> What I'd like to see happening is that we merge ctljack into jack (since
>>> only HDA is going to be affected by that change it seems like the right
>>> direction to make the merge) and also add extcon support, I have looked
>>> at the extcon support.
>> I don't know either why we have two different interfaces for jack
>> detection (not counting extcon) for driver writers. I think we
>> should merge jack and ctljack, as long as that does not mean you
>> break anything I'm relying on in ctljack.
>> Maybe something for discussion at Plumbers?
> We discussed this last time we all met and came to the above conclusion :/
>>> Short term for drivers used on embedded systems I'd have to recommend
>>> extcon rather than anything ALSA-specific.
>> I thought that when Takashi did the new ctljack interface, that
>> would effectively deprecate the old input device interface, and that
>> ctljack was the new recommendation.
> Android currently uses the out of tree version of the extcon ABI (like I
> say it's where the code originated), and some OSs do use the input ABI
> also but realistically if you've got to pick one Android is where the
> market is at.
So, it seems that the way to go is extcon. I guess that ALSA will use
extcon just like today snd_jack uses the input driver. is this correct?
Is there any chance that ctrljack will propagate the events through
extcon? Is there any early implementation that I could look at? I am
asking to know how feasible is to use ctljack today and be compatible
with extcon in the future.
> To my knowledge no embedded OS is using the control jacks, it's possible
> that there's something using them as a function of using PulseAudio but
> the ones I'm famililar with currently ignore PulseAudio routing and just
> use the mixing facilities. Given the dependency on alsa-lib it'd be an
> inconvenient ABI to adopt for most of them.
More information about the Alsa-devel