[pulseaudio-discuss] [PATCHv3 0/4] Read and store UCM data as proplist

[Tanu Kaskinen]

On Wed, 2011-05-11 at 12:43 +0100, Colin Guthrie wrote:
> 'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did gyre
> and gimble:
> > This is the third version of the Pulseaudio and UCM integration. 
> > 
> > This set of patches cover adding ucm data to proplist, adding a ucm API
> > to get and set data to proplist, and lets module-alsa-card scan ucm data
> > when the card is probed.
> > 
> > Another set of patches dealing with jack module detection will be sent
> > separately.
> 
> Thanks for this. I believe David will be helping review this stuff, but
> is currently at UDS.
> 
> WRT the jack detection, I think we all agreed that it needs to be
> handled more internally in the alsa code rather than separated as a module.
> 
> I'm not 100% sure of the finer details but I know David had ideas here too.
> 
> We basically need to match up the jack stuff with the appropriate
> sink/source device on the system and then develop a way to automatically
> change sink/source ports accordingly (it may also require that we change
> the card profile too - e.g. change from a 5.1 profile to a stereo
> profile when plugging in stereo headphones).
> 
> I'm not sure how to detect multiple jacks - e.g. if you plug in 3 jacks
> to do 5.1 output, should 5.1 be handled automatically?

FWIW, I'll share some thoughts I've had about jack detection (I have not
read the proposed code lately):

Ports should have a property called "available". (Some profiles don't
have any ports, so profiles would also have to have the "available"
status. Another possibility is to change this so that even single-mode
profiles would have a port, and I think this would actually be a better
idea than adding the "available" status to profiles.) The possible
values would be "yes", "no" and "no clue". Without jack detection, the
value would always be "no clue", because currently we have no clue
whether a port is actually connected to anything.

Whatever policy we want for automatically switching ports and profiles
should be in a separate module. It would follow the port availability
status and do something smart with that information.

Pulseaudio should have an abstraction for jacks. Jack objects would be
created by whatever alsa module is appropriate for that. Maybe
module-alsa-card would be the best choice, or maybe not. There exists
hardware where physical jacks are shared between multiple alsa cards. So
maybe module-udev-detect would be a better place than module-alsa-card
for creating the jacks, or maybe a new module is needed. The alsa
modules would then also have to match the physical jacks to the ports,
which may be tricky - some ports require multiple jacks to be connected,
and on the other hand multiple ports can share one jack. Anyway, the
status of the jacks associated with a port would determine the
"available" status of the port.

Something to keep in mind is also that one physical jack can have more
states than "connected" and "not connected". The 3.5 mm jack in N900,
for example, can be used with headphones, headsets, microphones, or it
can be connected to a TV. These different accessory types should trigger
different ports to be activated. So, either the jack objects in
Pulseaudio would need to have more than two possible states, or the
physical jacks should be mapped to multiple abstract jacks for each
accessory type. I'd probably go with the multiple abstract jacks with
simple on/off status.

-- 
Tanu