[pulseaudio-discuss] [RFC v0 0/5] Add card profile availability

[David Henningsson]

On 02/14/2013 08:50 AM, Mikel Astiz wrote:
> Hi David,
>
> On Thu, Feb 14, 2013 at 8:05 AM, David Henningsson
> <david.henningsson at canonical.com> wrote:
>> On 02/13/2013 02:48 PM, Mikel Astiz wrote:
>>>
>>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>>>
>>> It has been recently discussed how ports should be used in the Bluetooth
>>> card module, whether they should be merged or not, and how the
>>> bluetooth-related information is exposed to both external components (i.e.
>>> UI) and internal policy modules.
>>>
>>> In a nutshell, the problem is as follows: the internal policies are
>>> interested in profile-specific information (HSP/HFP vs A2DP) while the ports
>>> should ideally be associated to physical entities (and the Bluetooth profile
>>> should make no difference).
>>>
>>> A natural way to solve this problem is by adding a new flag to the card
>>> profiles, representing the availability of each profile. This is similar to
>>> port-availability but with different semantics, representing the state of
>>> each invidivual Bluetooth profile.
>>>
>>> This patchset extends the core with such a flag, which sounds useful even
>>> beyond the scope of this specific problem (a UI could use this information
>>> to gray out profiles).
>>>
>>> If the core adopted such a flag, the merge of the Bluetooth ports would be
>>> straightforward, as implemented in patch v0 5/5.
>>
>>
>> Just trying to understand it:
>>
>>      if (state == PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED)
>>          return PA_PROFILE_AVAILABLE_NO;
>>      else if (state >= PA_BLUETOOTH_TRANSPORT_STATE_PLAYING)
>>          return PA_PROFILE_AVAILABLE_YES;
>>      else
>>          return PA_PROFILE_AVAILABLE_UNKNOWN;
>>
>> If the state is "disconnected", why is there a card at all at that point?
>
> A card can have multiple transports, one per Bluetooth profile and
> role. These map to card profiles in module-bluetooth-device, with the
> exception of profile "off".
>
> Roughly speaking, the modules gets loaded when at least one profile
> gets connected, but there is no guarantee about the state of the rest.
> That's why PA_PROFILE_AVAILABLE_NO provides valuable information,
> exactly as PA_PORT_AVAILABLE_NO did before (assuming the ports are not
> merged).
>
>>
>> And if there isn't, then it's just showing whether it's playing back or not,
>> which can be retrieved by just checking the actual sink/source state?
>
> The sink/sources do not exist unless the profile is active. As an
> example, if the card is set to profile "a2dp", the only place where we
> expose whether HSP/HFP is actually streaming audio is: (a) before this
> patchset -> in the availability of "hsp-input" (which we were not able
> to merge with port "a2dp-input"), and (b) after this patchset -> in
> the availability of profile "hsp".

After some discussion on IRC I can't say that I fully understand the 
entire object model of BlueZ and how that correlates to different PA 
objects; but adding a profile availability doesn't seem to cause any 
significant problems in itself, so if it solves your problem, go ahead! :-)



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic