The msbc capability connection probe seems to cause problems on Intel
Bluetooth 8087:0a2b (Intel 8265), resulting to subsequent connections
apparently ending up with wrong altsetting.
According to testing, the problem is connecting to self, so connect to
device instead.
Fixes#1671
There is a report (#1342) of a device setting multiple bits for AAC
object type in SetConfiguration, although this appears to be forbidden.
It's not completely clear if this was due to e.g. some BlueZ bug, but it
should be safe to be lax and try to guess what is wanted in such case,
instead of being strict, in case it was due to device bug.
Previously, `log-patterns.c` was included in two other source files
(`journal.c` and `logger.c`). It was also specified in the sources
list for the libspa-support library, which resulted in the unnecessary
independent compilation of the file, generating "defined but not used"
warnings.
Extract the function definitions into `log-patterns.h` and
use that in `journal.c` and `logger.c`, and remove the inclusion
of `log-patterns.c` from both.
Don't use the previously skipped sample to calculate the remaining
amount of samples or else we remove one sample too much in some cases
and cause distortion, mostly when downsampling.
Fixes#1646
Intel 8087:0029 at Firmware revision 0.0 build 191 week 21 2021 on
kernel 5.13.19 produces CVSD data stream that consists of 96-byte data
packets interleaved with 96-byte zero packets.
This seems to not occur on other adapters, which usually produce only
48-byte data packets.
Don't do a blocking probe of native backend presence, because it may
trigger DBus activation for Bluez. If the DBus activation fails, it
ends up blocking until timeout.
ofono/hsphfpd usually don't have DBus activation configured, so they
fail instantly (which is why this problem was not encountered, even
though they do blocking calls on startup in previous pipewire versions
too).
Instead, select the backend once we have Bluez objects listed.
HAVE_DATA|NEED_DATA signals that the graph can continue processing.
OK means that the node will continue asynchronously later. This
is needed to make the dummy driver work as a follower.
BlueZ 6 is planning to make most of libbluetooth private. In
particular, the direct hci access is planned to be removed. This is
currently used for determining adapter msbc support.
Instead of using libbluetooth API, try to determine msbc support by
a connect() attempt, which the kernel should reject when not supported.
The requests_ vector contains the requests created for a camera on start()
but the vector elements are not removed on camera stop(). This leads to a
segfault, when these requests that are no longer valid are queued again.
Also move the streamName_ map clear to LibCamera::stop() where it should
be, since its elements are added in the LibCamera::start() function.
The camera is connected in the spa_libcamera_stream_on() function but the
disconnect happen in LibCamera::stop(). It makes more sense to have this
two operations separated as it's done for the connection and start, since
the camera then can be stopped/started without needing to do a reconnect.
Move the camera disconnect to spa_libcamera_stream_off() for the reason
mentioned above but also to make the code more consistent and symmetric.
Camera is currently stopped and started in the spa_libcamera_set_format()
function, but this leads to a segfault due attempting to access a buffers
field of an already freed libcamera::FrameBufferAllocator instance.
The FrameBufferAllocator instance is freed in LibCamera::stop(), that is
called by spa_libcamera_stream_off() as handler of the node commands
SPA_NODE_COMMAND_Pause and SPA_NODE_COMMAND_Suspend.
Since the camera was already stopped, there's no need to attempt to stop
it again. In fact, the camera shouldn't be stopped/started at all in the
spa_libcamera_set_format() function but instead only as an action of the
SPA_NODE_COMMAND_{Pause,Suspend} and SPA_NODE_COMMAND_Start commands.
And same for the stop that's done in the LibCamera::close() function, it
shouldn't be needed because the camera is already stopped before closing.
Fixes#1513
There is no need to set and validate the configuration when the camera
is started, since this was already made when the camera was opened.
The configuration only needs to be set again if the port format changes
due a SPA_PARAM_Format parameter.
For SPA libraries that we link against elsewhere in the tree, declare a
declare a dependency "foo_dep" for that library that specifies how to
link to it. Then use that dependency in the various targets.
This removes the knowledge of how to link with the library from the
target which can treat it as just another dependency.
In the case of optional libraries (e.g. the journal support lib) we can
then use declare_dependency() to declare an empty dependencies and thus
link them unconditionally in the target.
