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.
Kernel-provided MTU does not work for USB controllers and the correct
packet size to send can be known currently only from RX. So we are
waiting for RX to get it.
The known problem is USB-specific, we shouldn't need the workaround for
other transport types.
Don't wait for POLLIN for non-USB controllers on connect, but ready
things on POLLOUT as usual.
For non-USB controllers, pick some sensible packet sizes to use
initially, before we switch to same size as for RX.
BlueZ API as BAP Server gives us the ISO interval, instead of the SDU
interval, in the MediaTransport.QoS.Interval property. They are not
necessarily the same. What we need is the SDU interval.
The SDU interval is the interval between packets the encoder outputs, so
it is determined by the codec configuration, and for LC3 is equal to the
frame duration.
Add codec method get_interval() that returns the correct interval, and
use it in iso-io.
Add some option to set manually group IDs of unicast streams
of devices.
Intel controllers don't appear to support more than one group at a time,
but in principle this can be done.
The file is moved into a new "include-private" directory. This is done
because otherwise adjustments would have to be made to the list of installed
headers, the way include tests currently work and which files are
used for generating documentation.
Reduce fallback delay values used when BT device doesn't provide the
information itself.
It may be better to have audio late than early, so use values that are
probably close to or below the delays of majority of headsets.
The PAC profile UUIDs do not appear in the UUID list, but are still
useful to know before SelectProperties.
Set them ahead of time based on the visible remote endpoints.
The "default" codec is the one with fill_caps != NULL, and should be
picked if we don't know which one we are using.
Fixes showing AAC-ELD as supported when it's not, which happened because
it's ordered before the default AAC in the codec list unlike the other
"shared endpoint" codecs.
Not waiting for HFP when no HFP backend should be checked via
adapter_connectable_profiles in spa_bt_device_check_profiles where the
relevant logic is.
Cleanup by moving the checks there.
