[pulseaudio-discuss] [PATCH 3/6] Cards now has ports directly, and device port has list of profiles
david.henningsson at canonical.com
Wed Nov 9 06:12:33 PST 2011
On 11/09/2011 01:50 PM, Arun Raghavan wrote:
> On Tue, 2011-11-08 at 16:00 +0530, Arun Raghavan wrote:
>> On Thu, 2011-11-03 at 21:04 +0200, Tanu Kaskinen wrote:
>>> Somehow keeping a list of profiles in the ports doesn't feel right -
>>> it's as if that list would have been thrown there just to make things
>>> convenient for some random code... But I guess there's a reason, which
>>> just isn't apparent from this patch yet, for having that list there.
>> This is my largest concern as well. It's the same concern that I had
>> with Mengdong's suggestion that profiles should have an intended role --
>> this feels conceptually incorrect, but becomes necessary because we
>> don't know anything about the sink that will appear when the profile is
>> So this is my proposal -- all possible sinks for a card should be
>> created upfront, in an "inactive" state. This way, from both the
>> jack-detection and routing fronts, we can see what sink we want, and if
>> it is inactive, we activate it by going to the profile it "belongs" to
>> and activating that (clearly some conflict-resolution will be needed
>> here too).
>> This isn't a trivial change, but it's something that's been coming up
>> repeatedly, and I'd be much happier if we took a little longer and did
>> it right.
> Just to expand on the idea since my post was a bit sketchy (I'm talking
> about sinks only for simplicity, but the same applies for sources as
> 1. Cards will create all sinks that might ever be created during profile
> switches. This will basically need a refactoring of pa_sink_input_new
> into two parts -- one for init only, one for registration.
> 2. Everything except the sink(s) related to the active profile will not
> be in the core sinks list (=> nothing that's not looking for these
> inactive sinks will see them). We'd have an inactive_sinks list for
> these (and these will have a new INACTIVE state (nomenclature can be
> chosen as anything)).
> 3. Corresponding to the registration step, there will be a
> deregistration step to bring the sink back to the INACTIVE state.
> 4. Profile switches basically now only register/deregister sinks.
> In the short run, we have a (IMO) cleaner architecture. In the long run,
> this will provide a lot more metadata that can be used in routing
> I hope this is clearer.
I'm not sure I agree that this is a cleaner architecture. As long as
nothing is actually using the stuff, the extra objects seem mostly
superfluous to me.
I can see an advantage though: if two profiles now can share sink object
(is that part of your idea?), then one could potentially switch from e g
"Analog Stereo Output" to "Analog Stereo Duplex" without a glitch on the
sink side. I'd like that.
But; I persist in saying that this is something to be separately
considered, and after merging the existing jack detection patches.
Especially so if you're going to build on top of them.
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss