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

[David Henningsson]

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