[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