On Thu, 2013-02-07 at 10:48 +0100, Mikel Astiz wrote:
> On Wed, Feb 6, 2013 at 5:09 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > After some discussion in IRC, it looks like something like this might be
> > acceptable to everyone (well, the involved parties have been just Mikel,
> > David and me):
> >
> > Keep ports as the concept that represents the physical device, e.g. a
> > Bluetooth headset. This ensures that existing applications don't need to
> > be changed.
>
> Agreed.
>
> > Create a new concept for "connections to ports", e.g. A2DP output and
> > HSP output. One name for this concept that has been used is "slave
> > port", but I'd really want to use something with no "port" in the name.
> > Suggestions are very welcome. My suggestion is "route".
> >
> > Does this have anything to do with the policy system that Janos and
> > Jaska proposed? Not much. This proposal doesn't require the "node"
> > concept, and doesn't conflict with it either (so it's still something
> > I'd like to have). Ports would be nodes, as originally planned.
> > Information needed for conflict resolution would have to be attached to
> > the "route" objects instead of nodes (for example, the A2DP routes
> > conflict with the same card's HSP routes).
>
> Adding a new abstraction or concept ("route") is something I would
> rather avoid if possible. That's why I initially liked the "slave
> port" approach, because it would reuse ports with a minor extension (a
> flag).
>
> After our discussion I agree that the "master/slave port" approach can
> be misleading and, without wishing to discuss in circles, I'd like to
> first consider other alternatives before adding such "routes".
>
> I believe the key question is whether we need cross-card "routes". In
> the case of Bluetooth, this requirement is not valid, regardless of
> whether SCO is routed through an alsa card or not. Therefore, the only
> remaining example I'm aware of is the following:
>
> On Wed, Nov 28, 2012 at 8:51 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > Third example: on the N9, wired headphone output can be done through two
> > alsa cards. It depends on the use case which one makes more sense. Like
> > in the previous example, ports of two separate cards would have to be
> > merged, if we wanted to make ports match 1:1 with physical endpoints.
>
> If we could agree that this scenario can be modeled without cross-card
> ports (i.e. one alsa card exposing both ports?), chances are that we
> can come up with a simpler design and avoid "routes".
>
> In this optimistic case, I can think of the following alternative to
> model the Bluetooth problem (where remember: availability and
> priorities should be profile-specific, and thus merged ports are not
> convenient for internal use):
>
> We could add availability to sink/sources by means of a new state:
> PA_SOURCE_UNAVAILABLE. This would allow modules to register
> sinks/sources even while the card profile is not active, effectively
> making them similar to "slave" ports or "routes".
>
> The adoption of this new state could be smooth because (a) this new
> state would be "hidden" externally not to break external API, and (b)
> modules could incrementally adopt this new core feature (with the
> possible exception of policy modules).
I very much like the idea of having sinks and sources available for the
whole duration of the card (this is what I previously meant by combining
ports and sinks/sources). I'm not sure I like PA_SOURCE_UNAVAILABLE as
the name for the new state, because the source can easily be made
available, so is it really unavailable in the first place? But that's a
trivial issue (if the state is not visible to clients). I'm not having
any better ideas right now either.
--
Tanu
