[pulseaudio-discuss] [PATCH v0 00/20] Revisiting Bluetooth modules
mikel.astiz.oss at gmail.com
Wed Aug 22 01:08:13 PDT 2012
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(-)
More information about the pulseaudio-discuss