Don't try to reconnect or wait for profiles, which cannot be connected
because the adapter doesn't have the counterpart sink/source profile.
E.g. we should not reconnect/wait for HFP HF on remote device, if
we don't have the corresponding HFP AG.
If A2DP remote does not acquire its pending transport within a timeout,
we won't get a write error in a2dp-sink, but instead the transport
becomes idle. Currently, we continue writing to the socket as if
everything was fine, even though the data won't be processed at the
remote end.
Handle this by stopping the node and emitting a node error event.
Pipewire may then restart the node to retry.
If the follower of the adapter emits an error event, the adapter needs
to forward it to upper levels so that they know the node has errored,
and handle the situation.
Endpoints without decode/encode capability are skipped in the object
manager, but we should also skip them in the registration calls (even
though in practice this doesn't appear to matter).
When filling up the channels, either fill up the positions with one
of the know layouts or use AUX channels, never try to mix them.
This avoid cards with a large number channels to show a strange mix
of surround and AUX channels.
Register a pthread cleanup handler to guarantee
that `spa_source::{priv, rmask}` are cleared even
if the thread is cancelled while the loop is dispatching.
This is necessary, otherwise `spa_source::priv` could point
to the stack of the cancelled thread, which will lead to
problems like this later:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f846b025be2 in detach_source (source=0x7f845f435f60) at ../spa/plugins/support/loop.c:144
144 e->data = NULL;
[Current thread is 1 (LWP 5274)]
(gdb) p e
$1 = (struct spa_poll_event *) 0x7f845e297820
(gdb) bt
#0 0x00007f846b025be2 in detach_source (source=0x7f845f435f60) at ../spa/plugins/support/loop.c:144
#1 0x00007f846b0276ad in free_source (s=0x7f845f435f60) at ../spa/plugins/support/loop.c:359
#2 0x00007f846b02a453 in loop_destroy_source (object=0x7f845f3af478, source=0x7f845f435f60) at ../spa/plugins/support/loop.c:786
#3 0x00007f846b02a886 in impl_clear (handle=0x7f845f3af478) at ../spa/plugins/support/loop.c:859
#4 0x00007f846b172f40 in unref_handle (handle=0x7f845f3af450) at ../src/pipewire/pipewire.c:211
#5 0x00007f846b173579 in pw_unload_spa_handle (handle=0x7f845f3af478) at ../src/pipewire/pipewire.c:346
#6 0x00007f846b15a761 in pw_loop_destroy (loop=0x7f845f434e30) at ../src/pipewire/loop.c:159
#7 0x00007f846b135d8e in pw_data_loop_destroy (loop=0x7f845f434cb0) at ../src/pipewire/data-loop.c:166
#8 0x00007f846b12c31c in pw_context_destroy (context=0x7f845f41c690) at ../src/pipewire/context.c:485
#9 0x00007f846b3ddf9e in jack_client_close (client=0x7f845f3c1030) at ../pipewire-jack/src/pipewire-jack.c:3481
...
AVDTP (v1.3 Sec 5.3) has a limitation that a local SEP (on the same
adapter) can be connected to at most one remote SEP. Trying to do have
it connected to multiple remotes either fails or causes misbehavior
later on.
Skip SetConfigure the same local endpoint for multiple remote ones in
codec switch. BlueZ observes this restriction in SelectConfiguration,
so also it won't try to do invalid configurations.
In BlueZ 5.64, the SetConfiguration calls succeed, but subsequent
transport acquires will fail. (Likely already the SetConfiguration DBus
call should fail.)
This all has the consequence, with the current approach to the
codec=endpoint correspondence, that if multiple devices are connected to
the same adapter, they currently have to use different codecs.
Improve the debug_params output.
Always either print the failed filter or that there was no filter.
Print the index of the enumerated failed param or a message when
there are no params.
See #2383
After emiting the node info, remove the properties from the info again
so that we don't accidentally emit them again later, when the
info and properties are out of scope.
Try 8 times to make progress, if nothing after that, xrun.
A stream that keeps sending 0 sized buffers would otherwise get into
an endless loop.
See #2359
The file name "lc3.h" in the ETSI LC3plus package may conflict with the
actual LC3 codec, so try to find a file "lc3plus.h" instead. Also try
to find a pkg-config dependency for it first (in which case use lc3.h,
assuming it's in different directory). This can be fine tuned, if
something starts to package that library.
LC3plus expands 509 bytes input -> 7680 bytes output, which is bigger
than current decode buffer.
Make the decode buffer bigger, and put it on heap, not stack.
Codecs may need to fragment a single encoder frame across multiple
packets that are sent consecutively.
Allow codec->encode() to set need_flush=NEED_FLUSH_FRAGMENT, so that
sink should immediately call start_encode + encode with NULL input data,
to produce the next packet.
Previously, other return values than need_flush=1 were unused, so no
need to bump codec ABI for this.
