SCO socket connect may fail with ECONNABORTED if it is done too soon
after previous close. To avoid this in cases where nodes are toggled
between stopped/started rapidly, postpone release until the transport
has remained unused for a time. Since this behavior appears common to
multiple SCO backends, do it for all SCO backends.
Move SCO polling to a single place, and abstract mtu handling.
Autodetect suitable tx packet size based on rx, instead of relying on
the kernel providing correct values.
Since the data thread accesses the spa_bt_transport, its destroy event
needs to sync with data thread to avoid races.
Also check transport is present in places that need it.
Simplify mSBC buffer handling and syncing to frame headers to work
on a per-byte basis.
The previous code could terminate with buffer overrun if it encountered
multiple consecutive incomplete packets.
When reusing buffers, do it in the same way as the other sinks.
The previous code did not set a valid next buffer for the i/o,
possibly causing it to hang.
Fixespipewire/pipewire#502.
Also move media application creating from filter callback to initialization.
Application object path and endpoint paths only need to be registered once.
Signed-off-by: Huang-Huang Bao <eh5@sokka.cn>
Backends don't necessarily allow for opening the same device multiple
times, and it shouldn't be necessary.
Since source and sink are not necessarily both running at the same time,
refcount the transport acquire/release so that it knows to close the fd
only when no source/sink is running.
Let the transport manage the fd lifecycle, also closing it once it is
not needed.
Don't return the fd from acquire(), since each transport is associated
with a single socket fd.
Instead of using a hardcoded value for the minimum delay between writes,
select it according to the mtu/packet size that is currently used.
This is necessary for correct playback with lower mtu values.
Kernel should provide the correct mtu/packet size to use for SCO socket
I/O, but it does not currently appear to (as of linux 5.9), see
https://lore.kernel.org/linux-bluetooth/20201210003528.3pmaxvubiwegxmhl@pali/T/
When using mSBC, instead of using the (incorrect) kernel-provided value,
hardcode mtu to 24, corresponding to ALT1 mode. BT-UART adapters should
not require specific mtu, and it appears most BT-USB adapters only
support ALT1, see
https://lore.kernel.org/linux-bluetooth/20201210012003.133000-1-tpiepho@gmail.com/
This code needs to be revised when the issue is sorted out on the kernel
side.
Add setting bluez5.msbc-force-mtu for easier debugging in special cases.
Leave read_mtu as the detected value --- it does not seem to affect
whether BT-USB can record, but Raspberry Pi BT-UART fails to record if a
different value is used.
oFono tries to use the best codec when setting up the audio connection, so
the codec to use is known during call to `acquire` function, after the
transport has been created.
To get the codec before creating the transport, an audio connection is
set-up and discarded during `ofono_audio_card_found()`. It should return
the best codec available, which should not change during the time the
remote is connected.
mSBC can be enabled by passing "bluez5.msbc-support=true" parameter to
pipewire-media-session.
mSBC is automatically selected if remote device supports it.
