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
