[pulseaudio-discuss] [PATCH 3/6] Cards now has ports directly, and device port has list of profiles

[Arun Raghavan]

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
> activated.
> 
> 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
well):

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
decisions.

I hope this is clearer.

-- Arun