Newer glibc versions have made certain `str*()` functions into macros
that ensure that the const-ness of the argument is propagated to the
return type.
This function is run for all the nodes with the data loop locked. It can
be used to atomically update multiple node controls.
We can't use the control_changed function because this one runs without
the lock and might do slow things, like what the sofa plugin currently
does.
See #5019
don't read the control ports from the processing thread and check for
updates. Use the control_changed signal to check and update the
parameters of the biquad atimically.
See #5019
Move the card->ignored check to only apply to ACTION_CHANGE, not ACTION_REMOVE. This ensures that ignored cards can still be properly removed when they are unplugged.
With keepalive enabled, we need to emit state change event on acquire
similarly as we do if refcount was already positive.
Co-authored-by: Martin Geier <martin.geier@streamunlimited.com>
When setting up the mix matrix, don't just iterate over the first 64
(CHANNEL_BITS) positions because then we will never be able to configure
more than 64 channels in the matrix.
Instead iterate until we have filled all src and dst entries in the
matrix. For the first 64 positions we might need to check the channel
mask to get the right positions in our source matrix.
Fixes the channel mixer for >64 channels where the positions above 64
where 0 in the matrix and muted.
Fixes#5118
Depending on the codec kind, select appropriate settings to pass
to select_config().
This allows to pass the bluez5.bap.force-target-latency property,
and so to select the same configuration.
Some PTS tests (e.g. BAP/UCL/SCC/BV-046-C or BAP/UCL/SCC/BV-077-C)
requests to select QoS from low-latency or high-reliabilty.
The bluez5.bap.force-target-latency device property allows to force it.
For other values than low-latency or high-reliabilty the QoS selection
will use both tables to find the more appropriate configuration.
Only set rate_match rate to DLL correction when matching is active.
When ALSA is driver and not matching, set rate to 1.0 to indicate no rate adjustment needed.
DLL still runs for buffer level management but rate_match should not expose correction
when matching is inactive to avoid confusion during debugging.
Signed-off-by: Stanislav Ruzani <stanislav.ruzani@streamunlimited.com>
On some device combinations (MT7925 / Sony LinkBuds S) the low-latency
48 kHz QoS crackle.
It's probably better to default to high-reliability for those, until we
have proper quality vs. latency configuration in place.
sizeof(adapter) is larger than the big_entry->adapter and so the code
would copy too much. Instead only copy the strlen of the parsed
adapter, which we checked above to be smaller than the available size.
This doesn't copy the 0 byte because the memory is assumed to be 0
filled already by the calloc.
If the address is exactly the HCI_DEV_NAME_LEN, it will result in a non-0
terminated string, which may or may not be a problem...
By setting the hci handle (e.g. hci0) of the desired adapter, the BIG
config will only applied on that adapter. In case no "adapter" entry in
the config is given, it will be applied on all adapters.
Signed-off-by: Alexander Sarmanow <a.sarmanow@televic.com>
Commit 2942bae034 introduced parsing of
"SupportedFeatures" which uses a third DBusMessageIter pointer.
*** stack smashing detected ***: terminated
==389050==
==389050== Process terminating with default action of signal 6 (SIGABRT)
==389050== at 0x4F57B2C: __pthread_kill_implementation (pthread_kill.c:44)
==389050== by 0x4F57B2C: __pthread_kill_internal (pthread_kill.c:78)
==389050== by 0x4F57B2C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89)
==389050== by 0x4EFE27D: raise (raise.c:26)
==389050== by 0x4EE18FE: abort (abort.c:79)
==389050== by 0x4EE27B5: __libc_message_impl.cold (libc_fatal.c:134)
==389050== by 0x4FEFC48: __fortify_fail (fortify_fail.c:24)
==389050== by 0x4FF0ED3: __stack_chk_fail (stack_chk_fail.c:24)
==389050== by 0xBC1D1A1: remote_endpoint_update_props (bluez5-dbus.c:3137)
==389050== by 0xB53609F: ???
==389050== by 0x1DF: ???
==389050== by 0x61C17BF: ??? (in /usr/lib/x86_64-linux-gnu/libdbus-1.so.3.32.4)
==389050== by 0x1DF: ???
==389050== by 0xC5ED113: ???
Replace magic numbers (0x02, 0x05) with named constants BT_CODEC_CVSD
and BT_CODEC_MSBC for better code readability. Also remove redundant
zero initialization of num_caps field since the buffer is already
memset to zero.
The sco_offload_btcodec() function now returns void and only skips
offload setup when using the default datapath, simplifying the logic
and removing the need for explicit feature flag checks.
Add support for configuring the SCO hardware offload data path for
HFP/HSP profiles using the Bluetooth SIG-specified procedure. This
enables vendor-specific SCO offload integrations.
Changes:
- Add `bluez5.hw-offload-datapath` configuration property (default: 0)
- Implement `sco_offload_btcodec()` to set BT_CODEC socket option
- Add `SPA_BT_FEATURE_HW_OFFLOAD` quirk feature flag
- Apply offload configuration when creating SCO sockets if quirk enabled
- Document new property in pipewire-props.7.md
The datapath ID is configurable via device parameters and only applied
when the hardware offload feature flag is set in quirks, allowing
platform-specific SCO offload implementations.
Clamp the control values to their min/max.
Remove the default_control array, we can just restore the default with
the port_set_control_value(). Do this when no value has been set on the
port when we set up the graph. The avantage is that we calculate the
default, min and max correctly when they depend on the graph rate.
Fixes#5088
There is no reason to fail when there is no input or output port.
We can simply run the graph with what there is. Even if there is no
input or output at all, running one instance of the plugins is
possible.
Add a busy builtin plugin that has no ports and keeps the CPU IDLE or
busy for the give percent.
The filter graph has, after parsing, a default number of input and
output ports. This is based on the description or the first/last element
input and output ports. Pass this information in the properties when
we emit the info.
Don't use the number of configured input/output ports as the default
number of channels in filter-chain because this is only determined after
activating the graph. Instead, use the default input/output channels.
The result is that when you load filter-chain without any channel
layout, it will default to the number of input/outputs of the graph
instead of 0. This allows for the node to be visible in the pulseaudio
API.
Fixes#5084
Don't rely on the out_rate vs n_phases to decide on when to use the
inter resampler because the out_rate can change when we activate the
adaptive resampler.
Instead use a boolean that we can set at the start.
If we have in and out rates with a very small GCD, we might end up with
a lot of phases. Limit the number of phases to 1024 and switch to
interpolating mode. 1024 phases is enough to accurately interpolate
from.
Together with the MAX_TAPS limit we will never create a filter
size that overflows 32 bits.
Fixes#5073
A DMA buffer from a DRM device are typically accessed using API related
to a DRM device, e.g. Vulkan or EGL. To create such a context for using
with a PipeWire stream that passed DRM device DMA buffers applications
have so far usually guessed or made use of the same context as the
stream content will be presented. This has mostly been the Wayland
EGL/Vulkan context, and while this has most of the time worked, it's
somewhat by accident, and for reliable operation, PipeWire must be aware
of what DRM device a DMA buffer should be accessed using.
To address this, introduce device ID negotation, allowing sources and
sinks to negotiate what DRM device is supported, and what formats and
modifiers are supported by them.
This will allow applications to stop relying on luck or the windowing
system to figure out how to access the DMA buffers. It also paves the
way for being able to use multiple GPUs for different video streams,
depending on what the sources and sinks support.
Our AVX optimizations are really AVX2 so rename the files and functions
and use the right HAVE_AVX2 and cpu flags to compile and select the
right functions.
Fixes#5072
Add heuristic to resync streams if controller packet completion times
for different streams differ by too much. This likely indicates
controller has lost sync between the streams, and we have to reset
playback.
There's no way to do this properly. The ISO-over-HCI transport is badly
specified in Bluetooth Core Specification. Many controllers have broken
implementation of the current send timestamp read command, so packets
have no identifiers which ISO interval they belong to.
Controllers try to reconstruct the right interval based on
manufacturer-specific heuristics probably based on packet arrival times.
Kernel + USB introduce timing jitter, and playback sometimes desyncs and
packet from some streams are persistently sent some multiple of the SDU
interval off from the intended timing.
Try to determine this from packet completion latencies. This is
somewhat manufacturer specific, tested on Intel & Realtek, hopefully
works on others too.
There are known controller firmware bugs that cause packet completion
reports, mainly for ISO packets, to be missing.
To avoid getting stuck e.g. in ISO queue flushing, we should consider a
packet completed if sufficient time has passed even if controller (and
kernel) don't report it completed. Take 1 s as conservative timeout, the
expected values are some ms.
These firmware bugs also cause kernel to stop sending packets if too
many are left uncompleted, but we cannot detect that.
Update volume state on device set volume notifications.
When one device sends volume notification, CAP specifies volume on other
devices shall be synchronized too.
When session manager emits loopback nodes for profile autoswitch, we
need to indicate them in the Routes.
Otherwise, the port information in Pulseaudio API doesn't account for
them, and some apps (eg GNOME) misbehave, as the loopback node sometimes
doesn't have valid ports.
When using channel maps, the active map should be set using
snd_pcm_set_chmap(). This has to be called when stream is in prepared
state.
Track which of the maps the selected format has set, and set it in
do_prepare().
Setup initial HW volumes for BAP profiles similarly as done for A2DP.
As Client, retain the remote volumes as initial values, and as Server
use our own default volumes.
Also as A2DP Source, use the remote HW volume as initial value, if
available.
In the Client / A2DP Source modes session manager usually restores its
own volumes overriding what we set here.
These keys have not been used for a very long time. Debian code search does
not turn up any users either. There is also no such thing as "libcamera_capability".
These were created based on the `api.v4l2.cap.*` keys, but at the moment they
are not actually applicable to libcamera. So remove them.
Take active rate correction properly into account when dropping data on
overrun resync.
Drop data only for the currently processed stream, after data has been
consumed from it. Make sure the rate correction factor is updated after
this for the next cycle of the stream.
Also fix buffer fill level calculation: the fill level interpolation
should use node rate corr, not clock rate diff, since the calculations
are done in system clock domain. Fix same issue in fractional delay
calculation, and take no resampler prefill into account.
Later, we maybe need some more resampler APIs to avoid such details
leaking in.
Previously, stream could have its old rate correction locked in, and its
fill level would then end up off the target on the next cycle.