[PATCH 1/6] Jack detection kcontrol implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/11/2012 08:03 AM, Arun Raghavan wrote:
> On Thu, 2012-02-23 at 07:17 +0100, David Henningsson wrote:
>> Support the new jack detection interface implemented in Linux 3.3
>> (and Ubuntu's 3.2 kernel).
>>
>> Jacks are probed and detected using the snd_hctl_* commands, which
>> means we need to listen to them using fdlists. As this detection
>> needs to be active even if there is currently no sink for the jack,
>> so this polling is done on the card level.
>>
>> Also add configuration support in paths, like this:
>> [Jack Headphone]
>> required-any = any
>>
>> ...where 'Jack Headphone' should match 'Headphone Jack' as given by
>> ALSA (as seen in e g 'amixer controls').
>> "Required", "required-any" and "required-absent" is supported. Using
>> required-any, one can have several ports even though there is no
>> other indication in the mixer that this path exists.
>
> And it's in! :) Thanks for the great work and patience in getting this
> merged. Worked great on the 3.3rc6 kernel for me.

Nice to hear, and thanks for reviewing!

> I merged the
> whitespace/coding style/comment changes we discussed on IRC. Please keep
> these in mind for future patches and commits.
>
> There are a couple of things I'd like to see:
>
> 1. Availability information in pactl/pacmd (we spoke of this on IRC)

I'll see to that.

> 2. A way to avoid the volume spike on port change
>
> I believe there was discussion on the second on IRC a while back, and
> I'm not sure how feasible this is. Is it possible for us to defer
> enabling the actual output on the whatever port is selected till the
> volume change is applied (maybe some of the auto-mute work from the
> alsa-devel bits are relevant here)?
>
> Maybe a mute-set volume-mute cycle would work if it is physically
> impossible to prevent the output from going to a device is plugged in.

Hmm, I have not experienced any such spikes, but maybe that's related to 
not running flat-volumes, or which of the ALSA kcontrols are present or 
not. In some cases it might be that there is nothing we can do about it, 
when the kernel disables the auto-mute before we are notified of the 
jack change.

I don't know if we have discussed this that much, but both port changes 
and volume changes are essentially the same thing for us, changes to 
kcontrols. We should set both the volume and port in one single operation.

In wider terms, I believe the mixer code needs refactoring. (As a side 
note, this will also make UCM support cleaner.) And we need per-port 
volumes in the core. It's too late to start that work for PulseAudio 
2.0, but 3.0 would maybe be a good target for such a feature.

As a side note; we might want to apply my hacky fixups for the per-port 
volumes for 2.0, see [1]. I doubt that'll help against the volume spikes 
though.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[1] 
http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.precise/view/head:/debian/patches/0017-Hack-around-a-bug-in-the-core-causing-volumes-not-to.patch


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux