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.
This is a leftover from an earlier version of 0e60e9c063. The
attribute is not supported by clang at this time, so let's remove
the #define until we have a use-case that requires it.
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
Add a struct spa_log_topic that allows for logical grouping of messages.
The new macros spa_log_logt() and spa_log_logtv() take a topic as
argument, the topic's level acts as filter.
A new macro spa_log_topic_init() initializes a topic. By default a topic
inherits its logger's debug level but a logger implementation may set
that topic to a specific fixed log level.
The various spa_log_*() macros transparently wrap new and old
implementations:
- if the implementation is version 0, the new logt() calls drop the
topic and get routed into the old log() calls
- if the implementation is version 1, the old log() calls use a NULL
topic and get routed into the new logt() calls
All spa_log_* macros use the SPA_LOG_DEFAULT_TOPIC topic (NULL), it is
up to the caller to redefine that. Alternatively, use spa_logt_* to pass
an explicit topic.
There is one crucial flaw in this implementation: log topics are
initialized to their target level by the current logger. Where a topic
is initialized but the logger is switched later, the topic is not
automatically re-initialized. Ultimately this shouldn't matter for
real-world use-cases.
spa_interface_call() and friends will quietly do nothing if the version
doesn't match so we need an extra macro to know whether we can
spa_interface_call() for any given version.
This allows us to implement things like:
if (spa_interface_callback_version_min(1)
spa_interface_call(..., 1, func_v1)
else
spa_interface_call(..., 0, func_v0)
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.
spa_log_logv was missing, so with this ifdef'd out we already fail to
compile:
spa/plugins/alsa/alsa-acp-device.c:1003: undefined reference to `spa_log_logv'
And it appears that the only requirement is __VA_ARGS__ support in the
compiler which we require in other places anyway.
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.
