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 >> 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. 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. http://launchpad.net/~diwic
