Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
mmfw-sysconf-panda packages
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I doesn't make sense to require all callers of
pa_device_port_new() to create the hashmap themselves. There
are and there will be no cases where a port without any
profiles would be desired.
|
|
Stop the rate adjustment timer when no audio is flowing.
|
|
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.
|
|
At module-loopback load, if no sink is given, the default sink is used. If the
stream has a media.role property, the property cannot be used because a the
source or sink is forced to default. Both module-intended-roles and
module-device-manager are affected. The same apply to sources.
With this patch, if sink or source is missing, routing modules can be used.
|
|
This means only profiles on PA_BT_AUDIO_STATE_PLAYING state will have
bigger priority than 'Off'.
|
|
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.
|
|
Try to acquire the transport as soon as the audio stream is started,
along with the availability flag update.
|
|
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 initial state of a sink or source might not necessarily be IDLE,
because sometimes it might be suspended from the very beginning.
|
|
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.
|
|
Wrap the code parsing the PropertyChanged signal into a helper function
that will return the new state of the interface.
|
|
The function setup_stream() never fails so the code can be simplified by
just removing the return value.
|
|
The function bt_transport_config() never fails so the code can be
simplified by just removing the return value.
|
|
|
|
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.
|
|
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".
|
|
Else clause should be in the same line as the closing brace.
|
|
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.
|