Hi Tanu,
On Wed, Feb 6, 2013 at 5:09 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Mon, 2013-02-04 at 15:46 +0200, Tanu Kaskinen wrote:
>> On Mon, 2013-02-04 at 10:43 +0100, David Henningsson wrote:
>> > On 02/04/2013 09:59 AM, Mikel Astiz wrote:
>> > > We decided Immediately before 3.0 that some Bluetooth ports should be
>> > > merged (commit 40329acc1a28145643e49207e9d65cd05bbda2c8) but this is
>> > > basically UI-oriented and not very convenient for internal use, as
>> > > already discussed.
>> > >
>> > > In this case, I was tracking down a issue we have in
>> > > module-bluetooth-device, and the solution would be much simpler if we
>> > > had independent ports.
>> >
>> > So; if port are merged with sinks/sources, I assume you would like this
>> > merged object to be once per stream (i e different for a2dp and
>> > hfp/hsp), which would again break the UI?
>> >
>> > This looks like a problem with the approach of trying to merge ports and
>> > sinks/sources.
>>
>> I don't think merging ports with sinks/sources is the most relevant
>> question here. The question is how to simultaneously present a Bluetooth
>> headset as a single routing endpoint to the user and have means to
>> sufficiently distinguish between A2DP and HSP inside PulseAudio.
>>
>> I have proposed that we use the routing nodes of the policy work done by
>> Janos and Jaska to represent the headset as a single routing endpoint,
>> and associate multiple ports (A2DP and HSP) with that routing endpoint.
>> I would like to reach a consensus about this proposal. Is it ok for
>> everybody? David? Janos? Jaska? Please comment.
>
> 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).
Cheers,
Mikel
