[pulseaudio-discuss] [PATCH 3/6] Cards now has ports directly, and device port has list of profiles
arun.raghavan at collabora.co.uk
Tue Nov 8 21:55:57 PST 2011
On Tue, 2011-11-08 at 20:16 +0200, Tanu Kaskinen wrote:
> 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.
> I think I agree after all. I tried to come up with a better
> counterargument than "it doesn't feel right", but I failed.
Here's my reasoning -- if you look at this from a pure ALSA perspective,
profiles are a list of PCMs and associated mixer paths. Put this way,
the jack -> profile pointer could makes sense.
More generically, though, profiles represent some set of mutually
exclusive input/output paths. Defining them this way, there isn't really
a relation between the ports and profiles, only between the ports and
the input/output paths that the profiles represent. (which is why I
believe my alternative makes sense)
Looking at it merely as the code stands today, the first interpretation
makes sense -- we only really support ports on ALSA devices. But that's
only the short-term view, and IMO it makes more sense to take the
long-term view when defining your classes and their relations.
More information about the pulseaudio-discuss