On 2011-05-12 09:37, Tanu Kaskinen wrote: > 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. Agree with the port property. About the port vs profile question, I think we might think that backwards from a user's perspective. Conceptually I'd say we select port first (manually or automatic; doesn't matter for this reasoning), then we evaluate what profiles make sense to try. If we're on headphones, only stereo profile makes sense, if we're on line-out, we might want to consider surround profiles. At least I would want it to work that way in the UI. Could you elaborate on having profiles without ports? IIRC Pulseaudio would fail in this case. > 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. And that's what we're hoping Colin will write some time in the not too distant future :-) > 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. Really? Is that some embedded scenario? > 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. The matching can probably be done for HDA by parsing the event name (you can see this name in evtest) but we might need manual options for people wanting to set up the match manually. > 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. Agreed, one jack object for headphone connection, another jack object for microphone. A headset would typically activate both. The TV might be a third jack object. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
