Some devices appear to set Supported_Max_Codec_Frames_Per_SDU == 1 while
claiming they support two channels per stream, which is then not
possible.
In this case, limit the number of channels by the number of frames per
SDU when selecting.
Also adjust PAC sorting.
GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
./pipewire-0.3.84/spa/plugins/bluez5/codec-loader.c:176:14: warning: allocation of insufficient size ‘1’ for type ‘struct impl’ with size ‘1032’ [-Walloc-size]
```
The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```
So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct impl)`. GCC then sees we're not
doing anything wrong.
Signed-off-by: Sam James <sam@gentoo.org>
BlueZ now requires endpoints to set Locations/Context, so set them to
some sensible default values. These could in principle be made
configurable later.
Use bigger fallback maximum MTU, when kernel fails to tell us, which
shouldn't happen but apparently can. We choose the packet size based on
incoming data, so these values aren't usually needed so we can just bump
them.
Also report errors as necessary.
If remote supports both HFP HF and AG, both may get connected, which
occurs with Pipewire<->Pipewire connection. In this case, Pipewire on
both sides may pick the audio-gateway profile.
To avoid both sides being audio-gateway, if remote is both A2DP sink and
HF, use lower priority for the audio-gateway profile. Generally, BlueZ
won't connect both A2DP Source and Sink between same devices at the same
time, so we use that to determine which side should be the receiver.
It may occur that we have RFCOMM connected as both HF and AG. The codec
switching and support checks should in this case always use the remote
HF RFCOMM.
Fix by finding the RFCOMM with the correct profile, remote as HF.
Make supported codec checks to use profiles, not "is-a-sink" flag, to
determine which codecs can be used.
Fixes bluez5-device checking only source profiles, even when the local
device is only a sink.
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.
