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
The video-play-fixate example will downgrade the stream to MemFd one
modifier at a time. Sometimes it's useful to test with not downgrading;
to avoid having to depend on actual DRM devices (real or virtual), fake
them by using memfd and mapping them in the sink.
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().
When suspend_on_idle is set and we got to idle, there is a chance that
there is work in the work queue that is dependent on formats being set.
In suspend_node, check whether the links have a non-zero busy count before suspending and
return -EBUSY if they do.
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.
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.
