On 02/04/2013 04:07 PM, Tanu Kaskinen wrote: > On Mon, 2013-02-04 at 15:50 +0100, David Henningsson wrote: >> On 02/04/2013 03:44 PM, Tanu Kaskinen wrote: >>>>> 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 haven't fully understood the problem with having merged ports for A2DP >>>> and HSP - there are still different sources and sinks, so one could just >>>> look at the current active sink if that's what you need to know. >>>> >>>> I do understand that if something was modelled in one way, and then we >>>> had to do an emergency fix because the model caused regressions in the >>>> UI, the fixups become ugly as a result. What I don't know yet is why >>>> multiple ports for A2DP and HSP would be a better model inside >>>> PulseAudio from start? >>>> >>>>> 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. >>>> >>>> It is difficult to have an opinion without knowing more about the >>>> routing framework and what a routing endpoint really is. But even if >>>> this proposal gets implemented, still somebody needs to rewrite the UI >>>> to use routing endpoints instead of ports - which should be an argument >>>> against this proposal in the first place. >>> >>> Mikel knows the details of the problem that he's working on right now, >>> I'll repeat an argument that I have stated earlier: sometimes the >>> Bluetooth setup is such that the HSP audio is routed through ALSA and >>> the A2DP audio is routed through BlueZ. Having a single port for the >>> headset is problematic in this scenario. I'd rather have a separate >>> "routing endpoint" concept for representing the headset. Do you prefer >>> merging ports even in this case? >> >> If A2DP and HSP audio go through different sound cards, we have no >> possibility to merge them right now. >> >> Not that I have ever seen such a setup. Can it happen on desktop/laptop >> computers you buy in the store, or only on highly specialised embedded >> environments (which are likely to have their own UI anyway)? > > I have no idea about desktop/laptop machines. I know that 100% of > smartphones that I've worked with (i.e. 3 Nokia models) have used ALSA > for HSP, ...and at the same time BlueZ for A2DP? Or everything through ALSA? > but I expect there to be phones that use the "normal" > everything-through-BlueZ setup. I don't consider phone UIs any more > specialized than desktop UIs: in both cases, one UI codebase should work > with a wide variety of hardware. I don't think the Ubuntu Phone UI > developers, for example, want to care about the Bluetooth hardware > details. Okay, so how would PulseAudio autodetect that HSP and A2DP, even though belonging to different cards, actually are connections to the same physical headset? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
