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.
The AAC-ELD support was not properly tested on devices. In theory it
should be OK, but it's untested.
Bump it down in priority so it won't be selected by default.
Also log info on FDK-AAC AAC-ELD support status.
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.
Don't include the quantum in latency: the latency relative to graph
cycle start doesn't depend on the quantum. Instead, the audio packet
size determines it.
Enable the /Internal media class hack also for SCO.
Session manager can use this to adjust SCO sink/source media.class when
it is going to emit front-end nodes hiding the hardware ones.
The rfcomm list may contain various AG & HF ones, so the profile must be
checked everywhere they are looked up.
Fix the rfcomm lookups everywhere to do it.
Fixes Pipewire<->Pipewire HFP connections, and sending HFP HF commands
to HSP or AG.
HFP 1.9 adds LC3 as a possible codec in addition to CVSD & mSBC.
E.g. Pixel Buds Pro latest firmware supports it.
Add the RFCOMM side and codec selection for it.
Devices may advertise other values, but not certain they will work well
in duplex configuration.
E.g. my Samsung Galaxy Buds2 Pro emits buzzing sound with 48kHz duplex
input.
