[pulseaudio-discuss] [PATCH v0 00/20] Revisiting Bluetooth modules

[Mikel Astiz]

From: Mikel Astiz <mikel.astiz at bmw-carit.de>

This patchset revisits the mapping between Bluetooth (BT) and PulseAudio (PA) states, as well as how the PA infrastructure and APIs fit the BT use-cases, including desktop and IVI use-cases. The topic has already been discussed several times in the mailing-list and IRC.

There are quite a few changes but I'll try to describe them here in order to make the review easier. Also note that the result of applying these patches can be easily tested without external components other than PulseAudio, BlueZ and oFono (the later for HFGW).

The motivation for this can be summarized as follows:

(A) Lack of inconsistency: the states and transitions exposed by the card profiles in module-bluetooth-device are inconsistent and not easy to understand. For example, a card profile can be activated only if the audio is successfully set up (A2DP stream or SCO link up), but once the card profile has been set the audio can actually be suspended.

(B) Lack of separation between profile-module and policy-modules: module-bluetooth-device implements some policies that should be left out, to be handled by policy modules. For example, module-bluetooth-device sets the profile to "hfgw" automatically when SCO gets connected (BlueZ state transition to playing), but on the contrary doesn't handle any other transition, such as when the SCO gets disconnected. Similar policies exist in module-bluetooth-discover.

(C) Lack of integration with other PA modules: namely module-switch-on-port-available and module-suspend-on-idle include policies that can be interesting in the BT domain. It is desirable that these modules would gracefully integrate with the BT modules. Other interesting modules exist but haven't been addressed here.

Therefore the patchset mainly focuses on simplifying module-bluetooth-discover and rewriting module-bluetooth-device in order to address those problems.

The proposal consists of the following mapping in module-bluetooth-device:

(1) The module is loaded while at least one BT interface is connected (the term "profile" is avoided here not to be confused with card profiles). It was also this way before and it has been left unchanged, but the profile-handling policies have now been removed.

(2) The port availability flag is used to expose the audio state for each interface (disconnected, connected or playing). This includes the ports corresponding to unset card profiles, and is designed for both automatic policy-handling modules and manual operations using UIs.

(3) The card profile can be set at any time assuming the BT interface is not disconnected (so it's either Connected or Playing). This will however cause no side effect, so the audio will not start streaming due to such transition (in BlueZ terms, the transport will not be acquired unless the interface is already Playing).

(4) The sink-sources will be created as soon as the card profile is set, but they will be suspended unless the audio is streaming/playing.

The patchset can be divided into the following subgroups:

- Patches 1..5 propose minor changes and refactoring for later patches (grouped in the beginning for readability).

- Patches 6..7 propose some controversial changes that the following patches rely on.

- Patches 8..13 implement the new proposal for module-bluetooth-device, including the mapping described above. This is the main contribution of the patchset.

- Patches 14..18 focus on point (C) regarding the integration with other modules.

- Patches 19..20 are experimental and should not be applied yet.

It's worth mentioning that not everything has been addressed here. For example, the interactions with module-switch-on-connect or module-device-manager need to be fixed. Besides, PCM-based SCO-routing hasn't been considered in depth.

Looking forward for your comments.

Mikel Astiz (20):
  bluetooth: Remove return value of bt_transport_config()
  bluetooth: Refactor code to helper function
  bluetooth: Always config transport after acquire
  bluetooth: Refactor parsing of signal PropertyChanged
  bluetooth: Refactor hooks in module-bluetooth-policy
  sink,source: Support creating suspended sinks and sources
  Consider unknown availability in module-switch-on-port-available
  bluetooth: Set profile even if transport not acquired
  bluetooth: Provide dummy set_port callbacks
  bluetooth: Support port availability flag
  bluetooth: Do not acquire transport during profile change
  bluetooth: Acquire transport when becomes available
  bluetooth: Expose a single port for HFP/HSP
  bluetooth: Do not switch to HFGW automatically
  bluetooth: Do not set profile in bluetooth-discover
  bluetooth: Remove profile argument from bluetooth-device
  bluetooth: Avoid suspend-on-idle for HFGW
  bluetooth: Handle suspend in module-bluetooth-policy
  bluetooth-experimental: Fake input-output A2DP ports
  bluetooth-experimental: Fix race condition using accesstype "?"

 src/modules/bluetooth/bluetooth-util.c            |    1 -
 src/modules/bluetooth/module-bluetooth-device.c   |  321 ++++++++++++++-------
 src/modules/bluetooth/module-bluetooth-discover.c |   14 -
 src/modules/bluetooth/module-bluetooth-policy.c   |  132 +++++----
 src/modules/module-switch-on-port-available.c     |    2 +-
 src/pulsecore/sink.c                              |    7 +-
 src/pulsecore/sink.h                              |    2 +
 src/pulsecore/source.c                            |    7 +-
 src/pulsecore/source.h                            |    2 +
 9 files changed, 312 insertions(+), 176 deletions(-)

-- 
1.7.7.6