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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
