On Tue, 2011-05-17 at 13:44 +0200, David Henningsson wrote: > 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. No, Pulseaudio doesn't fail in the scenario that I'm talking about - the "no ports" situation is an optimization for the case when there would be only one port to select from. If the profile (or more precisely the mapping associated with that profile) has only one path in the mixer configuration, then the sink or source will not export any ports at all. The reasoning for that is probably that having a single port on a sink would be redundant, because currently the only functionality ports offer is that the user can change between them. However, if the "available" property is added to ports, then exposing even just one port on a sink will not be redundant. I'm not sure what you are proposing with regards to selecting ports. Did I understand correctly that the user should be presented with all ports of all sinks and sources of a card in one big list? > > 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? Yep. Simplifying a bit, one card handles the playback uses of the jack, and one card handles the capture uses of the jack. -- Tanu
