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
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.
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.
Also when we are capable of PLC, it's better to buffer audio at start,
to get a buffer level close to the target initially.
Delay ISO overrun handling one cycle after buffering is complete, so
that any resamplers are filled at that point.
When PLC data was produced due to underrun and decode buffer has reached
target level, drop received audio if we already did PLC for that packet.
It's better to lose some packets than having to resync latency.
When about to underrun when PLC is active, update rate matching before
filling up buffer, so that rate slows down and we do not get stuck in a
continuous underrun where PLC fills data and we drop received packets.
The rate matching filter assumes buffer level for cycle j+1 is
buffer(j+1) = buffer(j) + recv(j) - corr(j+1) * duration
but what we are actually doing is instead
buffer(j+1) = buffer(j) + recv(j) - corr(j-1) * duration
because the correction factor that is computed is not used for the next
cycle, but the one following that. Although the filter is still stable
in theory the extra lag causes oscillations to be damped less.
Fix by using the computed correction factor for the next cycle, as
there's no reason why we'd like to have more lag in rate matching.
This then changes c(j-1) -> c(j) in the assumptions, which turns out to
fix the situation. Fix the filter derivation to match. The filter
coefficients stay as they were, and they are actually exactly correct
also for short averaging times.
In practice, it is observed that ISO RX with quantum 4096 converges to
stable rate, whereas previously the matching retained small
oscillations.
The buffer level number includes the current quantum, so it should not
be subtracted. We do this after recovery from glitch, and this throws
rate matching off.
The level after recovery should also include the resampler delay.
As BAP server, when we can't satisfy BAP presentation delay, just accept
a bigger latency and emit a warning, instead of having broken audio.
Also make sure it works if quantum is forced to a larger value than our
wanted node.latency.
Take other latencies into account when selecting the wanted node.latency
for BAP Server.
Fix up port.params usage vs. user flag, which is not used here.
Reset decode buffer rate matching if we need to PLC due to underrun so
it doesn't get stuck at playback at increased rate if target is too
small.
For better start synchronization, we should wait until all ISO nodes
that are going to be started finish creating ISO io.
Add a separate ready flag for startup that is set when all Acquire
requests are complete.
Add options to control advertised delays supported.
Smaller delay needs smaller node.latency be used, so use 40ms as a
reasonable minimum preferred delay.
The HSP and HFP profiles expect that a device function only as an audio
gateway or as an headset, which is the normal behavior for a headset,
a hands-free car unit or a phone.
In case of a desktop, it can perform both functionalities, but there's
no interest to get them at the same time as the bidirectional audio
is already supported.
I'm not 100% sure if this was breaking SSE41 builds on the official build system (I'm building Pipewire
with a different process), but I suspect it was, because you can't combine these into a single translation
unit to sidestep it without including multiple copies of resample-native-impl.h which isn't desirable.
We sync the filter graph in two places, make a function so that both
places do the same thing.
Make node_reset clear the setup flag so that we don't have to do that
twice.
