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.
The resampler delay was off by one sample, so remove the corresponding
fudge factor here. This matters for BAP output synchronization.
The resampler has also some fractional delay, so there can still be
sub-sample offset between the original and resampled timelines. This is
not currently taken into account.
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.
Encoders and some decoders have additional internal latency that needs
to be accounted for.
This mostly matters for AAC (~40ms), as the other BT codecs have much
lower delays (~5ms).
Airpods don't follow the specification and set multiple bits in AAC
object type, including the ELD bit, but actually want AAC-LC. So check
the AOT in the right order.
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.
Interpolate buffer level to current playback position, and change its
definition so it directly corresponds to the total buffer latency. This
is also a bit simpler.
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.
Clean up route/profile building a bit so that it is easier to add new
device profiles.
Use names instead of magic numbers for the routes.
Fix marking BAP set input route unavailable by error due to magic number
off by one.
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.
Similarly as in spa_dbus, don't exit if bus goes down. Neither the
audio or midi Bluetooth backend reconnects to DBus, but they shouldn't
exit the process.
Use the helper instead of duplicating the same code.
Also add some helpers to parse a json array of uint32_t
Move some functions to convert between type name and id.
This gets the next key and value from an object. This function is better
because it will skip key/value pairs that don't fit in the array to hold
the key.
The previous code patter would stop parsing the object as soon as a key
larger than the available space was found.
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.
Claim that call waiting notifications are supported.
Required for some devices (e.g. Soundcore Motion 300),
as they stop sending commands if the reply to CCWA is not OK.
A new 'broadcasting' state is to be added in BlueZ. It is
functionally similar to 'pending', but for the Broadcast scenario.
Until now, on Broadcast sink side, the transports associated with a
scanned source would automatically be switched to pending. PipeWire
then acquired any transport that was pending.
This is to be changed, transports will now remain in 'idle' state
until the user calls transport.select on them from bluetoothctl.
This changes the state to 'broadcasting'. PipeWire will then acquire
these selected transports.
This way, the user can select to which sink he wishes to sync.
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 provides access to GNU C library-style endian and byteswap functions.
Windows doesn't provide pre-processor defines for endianness, but
all current Windows architectures (X32, X64, ARM) are little-endian.
Can be used to group ports together. Mostly because they are all from
the same stream and split into multiple ports by audioconvert/adapter.
Also useful for the alsa sequence to group client ports together.
Also interesting when pw-filter would be able to handle streams in the
future to find out what ports belong to what streams.
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.
