[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 14:21 +0100, David Henningsson wrote:
> On 11/08/2011 11:30 AM, 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.
> 
> There is nothing wrong with every port knowing what profiles that port 
> is a part of; it follows naturally with having port belonging to cards.

Only insofar as we consider the restriction that we can't see all
possible sinks is somehow fundamental.

> Looking at the paper that was the result of the desktop summit 
> discussion, there are lines between ports and profiles, indicating 
> pointers between them, or something similar. Sorry if I'm sounding harsh 
> here, but I prefer not to rewrite my code once again just because you 
> have changed your mind.

I didn't have the impression that this was all set in stone when we
ended our discussion in Berlin. The jack detection does change how some
of our concepts are used, so I think it's acceptable that it takes some
time to come to the "correct" solution (my idea below might be crack,
but let's not dismiss it on other grounds than it being
incorrect/infeasible).

> > 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.
> >
> > Thoughts?
> 
> Since I don't see how that is supposed to work out, nor agree with the 
> change in general, I'm not the right person to write code to do that 
> change. Should you nevertheless decide to do so, I suggest you merge the 
> already posted patch set first, then start working on that more radical 
> change.

In my experience, this rarely works -- code once committed rarely gets
fixed soon after. That said, I don't want to block this feature
indefinitely either. Let's continue discussing both ideas for now and
see where we are at the end.

-- Arun