Hi David, On Tue, Feb 5, 2013 at 8:44 AM, David Henningsson <david.henningsson at canonical.com> wrote: > On 02/04/2013 05:06 PM, Tanu Kaskinen wrote: >> >> On Mon, 2013-02-04 at 16:30 +0100, David Henningsson wrote: >>> >>> On 02/04/2013 04:07 PM, Tanu Kaskinen wrote: >>>> >>>> On Mon, 2013-02-04 at 15:50 +0100, David Henningsson wrote: >>>>> >>>>> 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? >> >> >> At the same time BlueZ for A2DP. >> >>>> 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? >> >> >> If the phone uses PulseAudio path configuration files for the ALSA >> configuration, the Bluetooth port could be flagged with a property. If >> the phone uses UCM, I think the UCM configuration should provide the >> information, and the port flagged accordingly. If an ALSA port is >> flagged that way, I guess alsa-card should not create a routing endpoint >> in that case. The endpoint would be created by module-bluetooth-device. > > > Routing endpoints aside, if it is a technical impossibility / major > inconvenience to have a single port for a single physical entity, one could > have a port property "master-port" which would link the ports together. Sounds good to me. So if I get this right, any port with such a property would be considered a "secondary" port, and therefore the UI would not show it, right? > > But how is exclusivity handled here? I mean, how would you encode the fact > that A2DP should not be used at the same time as HSP, if they don't belong > to the same card? This exclusivity can be represented with the profile switch in module-bluetooth-device, as it's currently done. If HSP/HFP audio (SCO) is implemented alsa-based (PCM routing), the module should have a pointer to the SCO sink/sources. See module parameters "sco_sink" and "sco_source". With this "master-port" approach, I believe these parameters should be replaced by something like "sco_input_port" and "sco_output_port". > > I mean, one of the basic properties of two different cards is that they are > independent of each other, if this is not the case, should we consider > merging the bluetooth and ALSA cards instead? (That is just brainstorming, > not an actual proposal) > > >> >> module-bluetooth-device in turn knows whether to use the ALSA port for >> its routing endpoint based on the Routing property of MediaTransport1. >> If the routing is "PCM" (as opposed to the normal "HCI"), it should >> search for an ALSA port with the magic property, and if found, associate >> that port with the new routing endpoint. >> Cheers, Mikel
