If BlueZ doesn't reply, it may consider the operation still active.
Try to Release the transport to get to a known state.
This can happen if device doesn't respond to operations in reasonable
time and BlueZ doesn't have its own timeout which is the case for BAP
currently (which is a bug there).
Log something less confusing when connection to remote device drops
unexpectedly.
Silence logging transport Release() error in cases where the transport
was simultaneously deleted.
E.g. LDAC doesn't have that. Add the missing guard that was accidentally
dropped in the rewrite.
Also explicitly filter out non-A2DP/BAP codecs that can't be used in
ensure_media_codec
Unicast BAP codec switch requires CIG reconfiguration, which cannot be
done if there is an acquired transport.
When doing BAP codec switch, disable nodes of other devices sharing the
same CIG.
To avoid problems with node start/stop, just remove and re-add them.
Use SelectProperties() DBus API to reconfigure BAP unicast setup.
Add support to spa_bt_ensure_codec() to select whether to configure as
sink/source/duplex.
Simplify codec switching code: determine what switch to perform
immediately in spa_bt_device_ensure_media_codec().
The previous code doing "fallback" switching to various codecs is not
useful, as A2DP generally disconnects on the first failure and all
remote endpoints disappear.
Add iteration over multiple endpoints, for reconfiguring both source and
sink directions at the same time. This is in preparation of supporting
BAP reconfiguration (for A2DP there's usually only one direction
connected at a time).
config.h needs to be consistently included before any standard headers
if we ever want to set feature test macros (like _GNU_SOURCE or whatever)
inside. It can lead to hard-to-debug issues without that.
It can also be problematic just for our own HAVE_* that it may define
if it's not consistently made available before our own headers. Just
always include it first, before everything.
We already did this in many files, just not consistently.
Set different icons for A2DP & HFP output routes, so that they look
different (in Gnome).
Don't call the non-HFP output route as "headset" or "handsfree" in this
case, to be less ambiguous about microphone availability.
Also set device.icon-name for the device too.
While ASHA does not really use the D-Bus device set interface
but since ASHA has a device-wide HiSyncId and needs to handle
left and right side via a combine sink, use the device set
notion for ASHA as well.
ASHA devices with the same HiSyncId are a pair and this
will be used later on to set them up together with a
combine sink like device set for BAP. Side information
is required for channel information when setting up the
combine sink.
Use kernel-provided packet reception timestamps to get less jitter in
packet timings. Mostly matters for ISO/SCO which have regular schedule.
A2DP (L2CAP) doesn't currently do RX timestamps in kernel, but we can as
well use the same mechanism for it.
Add configuration options for the BAP/PACS sink and source endpoint
location (= channel positions) and context settings.
Although BlueZ associates these with individual endpoints, in the PACS
spec they are actually device-global, so configure directly in monitor
settings.
Parse BAP settings in a single place, and simplify QoS customization a
bit.
Ensure the selected preset gets selected.
For all the BAP codec settings, use device settings instead of global
monitor ones.
The current BAP QoS configuration allows to register a sampling
frequency based on the configuration done using wireplumber configuration.
However, for a scenario were the user need to use a specific SDU framelength
it cannot be done as the select_bap_qos function selects the QOS based on
priority and hence it will use the best possible config rather than the user
configured.
This PR adds option to select the QoS set based on user configured value. If
the remote device doesn't have the user configured capabilities it will always
use the best priority config.
Further, this change also allows the user to set RTN, Latency, Delay QoS config
for certain use case to have controller use optimum bandwidth usage.
Below are the example configuration on setting LC3 capabilities in config file:
bluez5.bap.set_name = "48_2_1"
bluez5.bap.rtn = 5
bluez5.bap.latency = 20
bluez5.bap.delay = 40000
bluez5.framing = false
Do not add/connect the profile for unconnected devices.
This fixes the issue where a previously paired ASHA device
would show up in the pavucontrol output device list even
when not connected.
This allows our a2dp-source (sink endpoint) to report delay to the
remote source endpoint. Setting the "Delay" property is already
implemented, but by failing to configure DelayReporting, bluez rejects
the property change.
Don't mix endpoint and transport paths, they're generally different.
If ASHA transport already existed, free the old one but not the device,
as the ASHA device existence should track how it appears in DBus.
G722 codec id for ASHA is chosen arbitrarily to be different from
A2DP and BAP codec IDs. ASHA spec does not specify a codec ID like
A2DP/BAP.
In places where codec_id comparisons are done, ensure that the check
is done against the codec of the right type viz. A2DP/BAP/ASHA.
Currently, the PipeWire daemon registers BlueZ LE Media Endpoints
with audio capabilities covering all settings defined in the BAP spec.
However, some scenarios might require the capabilities to be restricted
to specific configurations.
This adds a method to read LC3 codec specific capabilities from the
Wireplumber config file, and provide those settings when registering
Media Endpoint objects with BlueZ. If the values are not present in
the config file, all settings will be used by default.
Below is an example of how to set the LC3 capabilities in the config
file, to support the 16_2 setting from the BAP spec:
bluez5.bap-server-capabilities.rates = [16000]
bluez5.bap-server-capabilities.durations = [10]
bluez5.bap-server-capabilities.channels = [1, 2]
bluez5.bap-server-capabilities.framelen_min = 40
bluez5.bap-server-capabilities.framelen_max = 40
bluez5.bap-server-capabilities.max_frames = 2
For a BAP Broadcast Source endpoint, the QoS sync_factor enables the user
to adjust the Periodic Advertising interval based on the ISO interval
configured for the stream:
PA_Interval = sync_factor * ISO_Interval
Currently, this value is hardcoded to 2. This commit makes the sync_factor
configurable in the Wireplumber config file, along with the other config
parameters for BIGs.
When in A2DP sink role and remote end switches codec, BlueZ nowadays
appears sometimes emit first SetConfiguration (creating new transport),
and then ClearConfiguration (removing old transport).
Handle this case: emit profiles_changed event always when transports
come/go.
Redefine profiles_changed() to take bitmask of profiles whose connection
status changed, so we don't need to emit two remove+add events.
Now that BlueZ supports delay reporting in A2DP sink role, implement
that.
Report value that gives the total latency between packet reception and
audio rendering.
Also make Latency parameter in media-source to be not just a dummy
value.
Don't mark a profile disconnected, if it still has active transports.
For BAP, emit device set changed events when transports come and go, so
that the SPA device can reconfigure accordingly.
This adds support for BAP Broadcast transport links.
Unlike unicast, broadcast links are used by a BAP Broadcast Sink
device to link together multiple transports in the same BIG that
the user wants to start receiving audio from. Each transport is
associated with a different BIS, so each one has a different fd.
Thus, each link needs to be acquired and released separately.
Add spa_json_begin_array/object to replace
spa_json_init+spa_json_begin_array/object
This function is better because it does not waste a useless spa_json
structure as an iterator. The relaxed versions also error out when the
container is mismatched because parsing a mismatched container is not
going to give any results anyway.
Due to the how the kernel part of BlueZ computes the extended
advertising interval for a Broadcast Source, a sync_factor smaller
than 2 will result in an invalid interval value (too small).
This fixes the endianness of the parsed broadcast code. It also
fixes pontetial out-of-bouns write by using a bigger, temporary
bcode string, then, after checking it's length, copying it's content
to big_entry->broadcast_code.
Currently, the user sets the Broadcast Code via an array of integers
in the config file. However, the Bluetooth Core Specification indicates
that it should be set via a 16 byte string. This commit replaces the old
implementation with the one required by the spec.
Tested the commit with the example provided in the Core Spec:
Broadcast Code: Børne House
Result from btsnoop log:
< HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31
...
Broadcast Code[16]: 000000006573756f4820656e72b8c342
The result matches the example given in the spec.
Add "encryption" parameter to bluez5.bcast_source.config entry in
the configuration file. This allows the user to control the use of
Broadcast encryption.
