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.
6e581deb91 added an `spa_autoptr(DbusMessage) m`
for the new message sent out when a signal is received from modemmanager.
However this ended up shadowing the original `m` function arg,
so the code that wanted to interrogate the original arg with
`dbus_get_message_path` etc ended up interrogating this `NULL` value instead.
This triggered a NULL-check in `dbus_get_message_path` and caused
the process to abort.
Original downstream report: https://gitlab.com/postmarketOS/pmaports/-/issues/2886
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.
spa_loop_invoke from data loop to main loop is not OK, as Wireplumber
currently runs its main loop with "pw_loop_enter(); pw_loop_iterate();
pw_loop_leave();" which causes the loop to be entered only when it is
processing an event.
In this case, part of the time the loop impl->thread==0, and calling
spa_loop_invoke() at such time causes the callback to be run from the
current thread, ie. in this case data loop which must not happen here.
Fix this by using eventfd instead, which is safe as the callback always
runs from the main loop.
Eventfd is also slightly more natural here, as multiple events will
group to the same mainloop cycle.
Use TX timestamps to get accurate reading of queue length and latency on
kernel + controller side.
This is new kernel BT feature, so requires kernel with the necessary
patches, available currently only in bluetooth-next/master branch.
Enabling Poll Errqueue kernel experimental Bluetooth feature is also
required for this.
Use the latency information to mitigate controller issues where ISO
streams are desynchronized due to tx problems or spontaneously when some
packets that should have been sent are left sitting in the queue, and
transmission is off by a multiple of the ISO interval. This state is
visible in the latency information, so if we see streams in a group have
persistently different latencies, drop packets to resynchronize them.
Also make corrections if the kernel/controller queues get too long, so
that we don't have too big latency there.
Since BlueZ watches the same socket for errors, and TX timestamps arrive
via the socket error queue, we need to set BT_POLL_ERRQUEUE in addition
to SO_TIMESTAMPING so that BlueZ doesn't think TX timestamps are errors.
Link: https://github.com/bluez/bluez/issues/515
Link: https://lore.kernel.org/linux-bluetooth/cover.1710440392.git.pav@iki.fi/
Link: https://lore.kernel.org/linux-bluetooth/f57e065bb571d633f811610d273711c7047af335.1712499936.git.pav@iki.fi/
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 struct spa_error_location that holds information about some parsing
context such as the line and column number, error and line fragment
with the error.
Make spa_json_get_error() fill in the spa_error_location instead. Add
some error codes to the error state and use this to add a parsing reason
to the location.
Add a debug function to log the error location in a nice way. Also
add a FILE based debug context to log to any FILE.
Replace pw_properties_check_string() with
pw_properties_update_string_checked() and add
pw_properties_new_string_checked(). The check string behaviour can still
be done by setting props to NULL but the main purpose is to be able to
avoid parsing the json file twice in the future.
When using the old pw_properties_update_string(), log a warning to the
log when we fail to parse the complete string.
Use the new checked functions and the debug functions to report about
parsing errors in the tools and conf parsing.
This gives errors like:
```
> pw-loopback --playback-props '{ foo = [ f : g ] }'
error: syntax error in --playback-props: Invalid array separator
line: 1 | { foo = [ f : g ] }
col: 14 | ^
```
Check for JSON parse errors, and log error messages as appropriate.
It's mostly enough to do this where the input is parsed for the first
time, e.g. via pw_properties_new_string, as that already validates the
JSON syntax.
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.
Fix some sanity checks and add mtu check. Don't use
spa_return_val_if_fail here as it can spam stderr.
The buffer size check in codec_encode can't be hit.
Don't show a "codecless" profile for HFP, similarly as we do for A2DP.
Simplify codec handling: for HFP/A2DP there's at most one transport for
each profile, so no need to check it has right codec. There's also no
need for "fallback profile", we always just emit nodes for the transport
we find.
