Once Pipewire is started it will try to register a BAP broadcast source media endpoint on UUID 00001852-0000-1000-8000-00805f9b34fb if the media codec that supports BAP and the adapter indicates LE Audio is supported.
When the endpoint is detected (over DBus) by Pipewire and it has a broadcast sink UUID, a new device will be created with the address 00:00:00:00:00:00. This device will be our simulated remote device. This is done because a broadcast source emitting device does not need any connection to start transmitting the audio. This device is set as connected.
When the SetConfiguration DBus method is called and the spa_bt_transport structure with the profile BAP broadcast source is created we switch the device from the one read from DBus to the one created by us. This is done because in BlueZ, when the transport is created, at the Device property, BlueZ sets the adapter as the device that the transport is connected to. Here the device will have the newly created SPA_BT_PROFILE_BAP_BROADCAST_SINK profile connected.
Added code that allows to create a node in the graph for a device connected to the SPA_BT_PROFILE_BAP_BROADCAST_SINK profile.
This avoids the potential confusion when both codecless and codec profiles are
enumerated for A2DP.
Give base name to highest priority profile, so that best codec can be selected
at command line with out knowing which codecs are actually supported.
Some A2DP devices don't like reusing the same transport for different
media-sink instances, possibly because encoder is reset in between and
there can be a gap in transmitted audio.
This doesn't matter for SCO/ISO.
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.
Buffer sizes smaller than one cycle are possible, so don't assert that.
Instead, just provide as much samples as fits to the buffer.
If we are driver when this happens, emit a warning (once). Similarly to
ALSA, as driver we produce only one buffer at cycle start, and no new
buffers in process. If the whole cycle doesn't fit into the buffer,
recording probably will be broken and we want some debug when there will
be a bug report about that.
As far as I can tell, the code in question was not doing anything there
and was also breaking the new code elsewhere, so it was put on the
chopping block. Don't mind the squirming tentacles.
Signed-off-by: Niklāvs Koļesņikovs <89q1r14hd@relay.firefox.com>
Transport release should not be delayed if it is not active, since the
fd cannot be used any more, and the transport needs to be reacquired to
get a working fd.
Fixes reacquiring transports if the remote side causes them to become
inactive.
A DBusMessage needs to be unref-ed after sending it regardless
whether or not it was successfully sent. So do that in
`mm_dbus_connection_send_with_reply()` so that the callers
do not need to deal with that.
It is inherently racy, and we have a better way to ensure that
we won't autostart the service:
dbus_message_set_auto_start()
So use that.
This commit also adds a missing call to `dbus_pending_call_unref()`
and indirectly fixes a type mismatch (`dbus_bool_t` vs. `bool`)
that was present in `is_dbus_service_running()`.
The DBusError passed to `dbus_set_error_from_message()` must
be initialized, otherwise libdbus aborts:
dbus[129473]: arguments to dbus_set_error_from_message() were incorrect,
assertion "(error) == NULL || !dbus_error_is_set ((error))"
failed in file dbus-message.c line 4043.
This is normally a bug in some application using the D-Bus library.
The transport set volume call may take a long time or never complete, so
make them async to not block main loop.
Also reduce log level to info for the failed volume setting, as this is
something the user can do nothing about.
Do BAP audio location selection properly in SelectProperties, now that
BlueZ provides the supported locations there. Remove a previous
workaround.
The audio location in SelectProperties determines the audio channel
allocation, which determines the channel positions.
The duplex polling issue was due to spa_loop_add_source failing
when source and sink were both using the same fd. We now dup, so the
issue no longer exists.
Remove the now unnecessary workaround, and check the return values from
spa_add_source.
