On Wed, 2013-02-06 at 14:57 +0100, Mikel Astiz wrote: > Hi Tanu, > > On Wed, Feb 6, 2013 at 12:48 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > > On Tue, 2013-02-05 at 08:44 +0100, David Henningsson wrote: > >> On 02/04/2013 05:06 PM, Tanu Kaskinen wrote: > >> > 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. > > > > I don't think the Bluetooth module would implement ports for HSP in this > > case, so there would be no master port to link to. > > I disagree. We could always represent the master "bluetooth-input" and > "bluetooth-output" ports in the Bluetooth module. Furthermore, despite > the PCM-based audio routing, both ports (master and > "secondary"/"slave" - we would need some terminology here) should > belong to the Bluetooth module in my opinion. This is the only way to > give some meaning to port availability, for example, since multiple > devices are represented in the alsa card (let's say multiple HSP/HFP > headsets are paired and connected). Hmm, the hardware that I have experience of doesn't allow multiple simultaneous HSP headsets, but it's still a good point that the ALSA device is associated with multiple headsets. I agree that there should be a separate HSP port object for every headset, even if they can't be used simultaneously (there could be port settings that need to be kept separate for each headset; I can't give any examples, though). So, it looks to me like the ALSA card shouldn't create any ports for HSP. It still needs to implement the sink and source, and it needs to handle the conflict between Bluetooth and other functionality. That conflict can be handled with profiles: the ALSA card could have an HSP profile, which doesn't create any sinks or sources. When the ALSA HSP profile is active, the Bluetooth module can request the ALSA card to create the HSP sink and source, which would appear to the outside world to be owned by the Bluetooth card. This seems compatible with what you described, except that I don't see the need for a primary and secondary port for the HSP sink. One port owned by the Bluetooth card seems sufficient to me. -- Tanu
