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.
This function sends a DBusMessage on a DBusConnection
and sets the reply callback of the resulting DBusPendingCall,
as well as properly cancelling the pending call if anything fails.
Now that sinks/sources can do transport acquire asynchronously, remove
the workaround that made it synchronous. Do release still synchronously
however.
All exposed bluez devices should have an adapter specified at all times.
Adapter-less devices appear in some race conditions in BlueZ interface.
Require device has non-null adapter, in all cases before adding any
profiles (which exposes the device), and reject BlueZ profile connection
attempts in that state.
If an adapter gets removed by BlueZ, remove also all its devices, so
that device->adapter pointers stay valid.
It seems not uncommon that people have not properly configured ofono
running, which results to loss of HFP/HSP functionality. It's less
surprising if the backend selection is fixed in the configuration file,
and (by default) does not depend on running services.
Add a configuration file option for selecting HFP/HSP backend, and set
the default value to the native backend. Emit warnings if conflicting
backend services are detected to be running.
Also cleanup hfp/hsp backend handling a bit, now that it's mostly
abstracted behind an interface.
Keep all types of devices, only emit device info if device has audio profiles.
Heuristically add profiles based on bluez actions so device can still be connected
even without initial UUIDs info from signal InterfaceAdded for org.bluez.Device1.
Fixes#1330
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.
