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
