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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
