Handle availability changes in Bluetooth ports inside
module-bluetooth-policy. The implemented behavior is similar to how
module-switch-on-port-available behaves, but the conditions are more
relaxed and thus more profile changes are triggered.
When PA is doing gateway role, let module-suspend-on-idle resume the
audio stream automatically. This will work until the user (or the remote
side, which we also consider user-initiated) suspend the stream
manually.
Card profile hfgw should be no different from the rest, and thus no
internal policy inside module-bluetooth-device should decide to switch
to its profile automatically.
This should be handled by policy modules.
Handle the Playing->Connected transition gracefully by releasing the
transport and setting the sink and sources as suspended. This is
necessary since the IO thread might not encounter a HUP always.
Until today, setting the card to some profile resulted in a transport
acquisition, leading to audio stream setup. This is generally not very
interesting and even undesireable for HFGW use-cases, where the
Gateway role (the remote end) would typically request the SCO link.
Nevertheless, there is no safe way to implement such check without race
conditions, since the BlueZ's state can change between the state report
and the call to Acquire(). The chances for this to reproduce are quite
low though, since interface state changes are relatively slow.
This race condition requires that BlueZ's API is extended in order to
perform the operation atomically, which has already been discussed and
ack-ed in the BlueZ mailing list.
Note that this patch does not introduce a new race condition, since it
already existed before (the PropertyChanged->Acquire race condition,
affecting HFGW use-cases). It is just more explicit now.
If the acquisition of the transport fails, the profile should still be
set. In this case the audio is not actually streaming, so the sink and
source will be created but left suspended.
If the transport needs to be acquired later, for example because the
user wants to route the audio the remote device, the suspend flag should
have to be changed.
Use the port availability flag to expose whether a certain profile is
connected and whether it's doing actual audio streaming.
The proposed mapping is the following:
- Profile disconnected: port is unavailable
- Profile is connected (but not streaming/playing): availability unknown
- Profile is streaming/playing: port is available
The availability-unknown is specially interesting: it involves that if
the sink/source exists (corresponding card profile set), it is currently
in suspended state.
For example, for SCO cases (HFGW or HSP), this means the SCO is down. A
policy module would typically not change this, unless someone is really
trying to use the sink/source. This situation would be nicely handled by
module-suspend-on-idle, which would automatically connect SCO.
On the other hand, if the user wants to control the status of the SCO,
it will still be possible by resuming the sink or source (suspend=0).
This works out-of-the-box since most UIs would show to the user ports
whose availability is unknown.
The configuration of the transport that depends on the MTU should be
performed every time the transport has been acquired, since the
parameters depend on what the Media API provides. This requires to
update the parameters of the sinks and sources as well.
This patch moves this code into a new function that will be called
when the stream is starting (setup_stream), from the IO thread.
This makes the code more robust, since the existing multiple calls to
bt_transport_acquire() do not rely on setup_bt() being able to acquire
the transport.
There should be one port per sink/source so a dummy set_port callback
will be enough.
Adding this callback avoid the "operation not implemented" error
message and additionally makes the module work nicely with
module-switch-on-port-available.
The transport might have disapeared exactly before acquiring, so we
should avoid an assertion failure, in this case inside the function
pa_bluetooth_discovery_get_by_path().
The HFGW source should be consistent with the sink by not setting the
"phone" intended role.
Even though setting this role seems to make sense strictly speaking, the
rest of the codebase doesn't handle this well. Therefore, the audio
coming from a Bluetooth phone can be routed back to the same device.
Make code more readable by introducing the helper function
bt_transport_is_acquired(). This also adds assertions to check whether
the internal state is consistent.
Previously, sink_input_kill_cb would cleanup u->sink an then unload the
module. However, during module unload, both save_state and dbus_done
tried to use u->sink, causing a segfault or assertion failure.
The segfault is easy to reproduce: Load module-equalizer-sink and then
press ctrl-C to terminate pulseaudio.
This commit removes the u->sink cleanup in sink_input_kill_cb, since
u->sink will be cleaned up by the module's pa__done as well (after it
has been used).
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Interestingly, the name is properly matched even though there
is no paths/iec958-stereo-input.conf file.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
During initialization, the approach avoids having a needless short
period of corked state in case the sink is suspended, by always creating
the source-output corked and uncorking it immediately afterwards when
the sink is not suspended.
During initialization, the approach avoids having a needless short
period of corked state in case the source is suspended, by always
creating the sink-input corked and uncorking it immediately afterwards
when the source is not suspended.
Let device module figure out the priority based on the state of the
profiles.
Note that most likely all profiles will be in PA_BT_AUDIO_STATE_CONNECTED
state so 'Off' will be the initial profile then it is up to the policy
module to switch to the most suitable profile.
Add support for hfgw card profile in module-bluetooth-policy, just like
a2dp_source is handled.
In this case also the sink needs to be connected using module-loopback.
Instead of focusing on a2dp_source only, prepare the module to support
several profiles. It will be possible to enable/disable each of them
using module arguments.
Property bluetooth.protocol did make a distinction between A2DP sink and
source roles but on the contrary did not separate HFP roles (headset vs
gateway). For consistency, they should both behave similarly.
This automatically fixes another incosistency: the HFGW (or HSP) sink
was set to bluetooth.protocol="sco", while the source was set to "hsp".
There is no use for this distinction, since the protocol (including the
role) is the same.
Profile a2dp_source, just like any other card profile, should have
state guards when the profile is being changed. If the BlueZ interface
is not connected, the profile should be set to "off".
The return value of dbus_message_iter_next() doesn't need to be checked
since the while condition will be false anyway (arg type will be
DBUS_TYPE_INVALID).
The method ListDevices() in org.bluez.Adapter was deprecated in BlueZ
4.61, and is going to be removed in future releases. Instead, a property
was introduced for this purpose in BlueZ 4.7.
The method ListAdapters() in org.bluez.Manager was deprecated in BlueZ
4.61, and is going to be removed in future releases. Instead, a property
was introduced for this purpose in BlueZ 4.22.
The module module-bluetooth-device should never be given parameter
'profile' twice, even if both HFGW and A2DP are playing. This patch
proposed to consider HFGW first.
This simplifies the code a lot, in favour of the D-Bus Media interface
in BlueZ. The old socket-based IPC mechanism has been deprecated and is
about to be removed soon.
In UCM basic functions, we only assign intended roles from modifier
to sink/source, but we don't have a chance to set the ucm modifiers.
Here we amend the functions so that when roled stream starts or
stops, we have the following results:
1. stream will be routed to sink/source specified in modifier by
module-intended-roles
2. After that, modifier will be enabled or disabled.
3. when multiple streams with matched roles of modifier start, only
the first one will enable the modifier, and when they end, the
last one will disable the modifier.
Signed-off-by: Feng Wei <wei.feng@freescale.com>
Signed-off-by: Arun Raghavan <arun.raghavan@collabora.co.uk>
I know that pa_streq() is defined with an extra parenthesis, but everytime I
look at it, it makes me nervous. :D
So it's better to add the parenthesis here.
Modifiers may have their own PlaybackPCM/CapturePCM and for these, we
create separate sinks/sources. These are marked with the
device.intended_roles property to let role-based routing take care if
streams are tagged appropriately.
The proplist isn't used by the conventional alsa-mixer code path, but
can be used by UCM to transfer properties from UCM data to the
sinks/sources corresponding to a mapping. These properties could be used
later in policy, etc.
The specific use for which I'm writing this now is for UCM modifiers
that have their own PlaybackPCM/CapturePCM field. These will be
translated to a separate sink/source corresponding to the modifier by
adding an additional mapping per sink/source. These mappings' proplist
will be populated with the name of the modifier and corresponding
"device.intended_role" property. The latter will be used in the usual
routing-by-role way, and the former will be used during sink/source
activation and deactivation to know what UCM modifier is to be enabled
or disabled.
