[pulseaudio-discuss] Jack detection patches - overview
David Henningsson
david.henningsson at canonical.com
Tue Aug 30 08:57:35 PDT 2011
I've spent most of the day working with the jack detection patches and
they seem to be shaping up.
I just wanted to give you a rough overview of what they do to the
PulseAudio you used to know. ;-)
Basically they can be separated into three parts:
1) Core changes
Along with the discussions at the desktop summit, a card now has a list
of ports. Every port has an availability status (yes/no/unkown). Ports
also have an array of profiles for which that port is relevant (e g
digital ports are only relevant for digital profiles).
Since the same port is now referenced from both the card and the sink,
it has been turned into a reference counted object.
I've also added this info to the cli (pacmd), but how to show the card
ports and the port<->profile connection through the introspection API is
still pending.
When the availability status of a port is changed, a hook is fired. At
the moment, only module-switch-on-connect listens to that. (Once Colin
has made the priority lists policy thing, that would also listen, I assume.)
2) Changes in the alsa modules
Here's where the toughest stuff happens. In order to be able to fill in
the new structures, we have to probe all profile's paths at startup. In
order for this not to take too long time (and to make sure we don't get
more than one port entry for the same port), we now have a cache of
probed paths. Therefore paths are now owned by the profile set, and
since more than one path set can reference the same path, the path set
now have a hashmap of paths instead of a linked list.
3) Jack input device implementation
This part is the "controversial" part as the jack input devices that it
builds should be deprecated according to Lennart. It's the only thing we
currently have from the kernel though. The connection between a path and
a input device is configured in the path file:
[Jack_InputDevice]
name = Front
code = Microphone
...which basically means that the input device must support code
SW_MICROPHONE_INSERT and that its name must have "Front" in it somewhere.
So when an event comes in, the input device's path's port changes its
availability status, which makes module-switch-on-connect change the
current port (and sometimes profile). Piece of cake!
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
More information about the pulseaudio-discuss
mailing list