This replaces the manual check for "true" and some (inconsistent) return value
of atoi. All those instances now require either "true" or "1" to parse as
true, any other value (including NULL) is boolean false.
If oFono or hsphfpd are not installed, just log an info message
that they are not used. The native backend will work fine and we
don't want to log warnings.
See #971
This does not work as intended, because we no longer do a codec switch
on device connect. It should be done in a different way, but since it's
not used for anything right now, can as well remove it.
This will prevent to run the different backends concurrently.
The native backend will only register to BlueZ if neither oFono nor
hsphfpd are running. If one of them starts, the native backend will be
unregistered and the corresponding backend will register to its daemon.
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.
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.
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.
mSBC can be enabled by passing "bluez5.msbc-support=true" parameter to
pipewire-media-session.
mSBC is automatically selected if remote device supports it.
The audio agent gets or provides data in the format requested between host
and chipset.
The HSP and HFP profile request PCM data to be sent to the chipset which
will encode/decode them in CVSD format.
This audio agent format may be re-used later for another air codec hw
encoded.
So, rename the audio agent to be more explicit.
Release transport when endpoint connection property is updated to false.
This also checks if the transport is already created when receiving
endpoint properties update to prevent multiple transport creation.
The ConnectAudio method triggers Introspect and NewConnection calls from
hsphfpd to the backend, which will set the fd to use for the SCO data.
This imply to run the DBus loop while waiting for ConnectAudio reply to be
able to reply to those method calls.
MTU is hard-coded to 48. Using MTU from hsphfpd may prevent correct
sound operations.
Volume management is not yet implemented.
As hsphfpd is a prototype and its API subject to change, this backend is
disable by default.
This skeleton connects to hsphfpd daemon and list the managed devices.
