The delay is always expressed in samples at the output rate of the
resampler. For input streams we need to convert this to the expected
input rate.
Make the delay reporting in playback streams more accurate.
The resampler delay was off by one sample, so remove the corresponding
fudge factor here. This matters for BAP output synchronization.
The resampler has also some fractional delay, so there can still be
sub-sample offset between the original and resampled timelines. This is
not currently taken into account.
Resampler delay for N taps is N/2-1 input samples.
Add test that checks this.
When input rate is varying, the resampler also accumulates additional
sub-sample delay. The resampler does not currently have API to report
the instantaneous sub-sample delay. Add knownfail test for it.
In timestamps, support different clocks and local time as formats.
Local real time timestamps are useful when trying to correlate logs from
different sources.
When setting Route param, check that the route actually is part of the
active profile.
Also, check that the device given corresponds to the given route, before
setting properties. acp_device_set_port() also checks this, but we
shouldn't allow updating properties of Routes in non-active profiles.
Setting ports or applying props on devices not part of the profile can
do unexpected things e.g. alter mixer settings.
Don't mix endpoint and transport paths, they're generally different.
If ASHA transport already existed, free the old one but not the device,
as the ASHA device existence should track how it appears in DBus.
G722 codec id for ASHA is chosen arbitrarily to be different from
A2DP and BAP codec IDs. ASHA spec does not specify a codec ID like
A2DP/BAP.
In places where codec_id comparisons are done, ensure that the check
is done against the codec of the right type viz. A2DP/BAP/ASHA.
Make sure we only make the buffer for the follower larger when we
downsample because then we need to ask for more data from the follower
to fill up a quantum.
Never try to make the follower buffer smaller than the quantum limit.
The reason is that the graph rate could be decreased dynamically and
then we would end up with too small buffers.
See #4490
Load multiple graphs with audioconvert.filter-graph.N where N is the
order where the graph is inserted/replaced. Run the graphs before the
channelmixer.
Graphs can be added and removed at runtime.
Instead of recalculating what to do every cycle, we can prepare a
static schedule and just run that. We only need to reevaluate it when
something changes.
For input streams, first run the resampler and then the channelmix. This
ensures that the channelmix is run with the rate of the graph instead
of the rate of the input. This is nicer because rate and quantum align
with the graph and the sample accurate volume ramps will work as
intended.
For output streams, leave the resampler after the channelmix for the same
reasons.
Remove the chunk and add separate arrays with data and n_samples. This aligns
better with other methods and makes it possible to more easily reuse
arrays of pointers as input and output.
An input port has at most 1 link so we can avoid the loop and the
default port data. We can then also improve the logging and log
something when we set silence.
Both `spa_rectangle` and `spa_fraction` store unsigned numbers,
so print them as unsigned, the same way it is already done in
`spa_debug_strbuf_format_value()`.
When api.alsa.split-enable=true for ACP device, instruct UCM to not
use alsa-lib plugins for SplitPCM devices.
Grab the information from UCM for the intended channel remapping, and
add the splitting information to the nodes emitted.
Session manager can then look at that, and load nodes to do the channel
splitting.
The current biquad calculations are based on RBJ's cookbook [1],
except for low-/highpass. Since the filter configuration is also
based on using the definition of Q, it makes sense to also align
the remaining calculations to use the same filter cookbook instead
of using resonance which doesn't result in the same coefficients
as when using Q.
[1] = https://www.w3.org/TR/audio-eq-cookbook/
Currently, the PipeWire daemon registers BlueZ LE Media Endpoints
with audio capabilities covering all settings defined in the BAP spec.
However, some scenarios might require the capabilities to be restricted
to specific configurations.
This adds a method to read LC3 codec specific capabilities from the
Wireplumber config file, and provide those settings when registering
Media Endpoint objects with BlueZ. If the values are not present in
the config file, all settings will be used by default.
Below is an example of how to set the LC3 capabilities in the config
file, to support the 16_2 setting from the BAP spec:
bluez5.bap-server-capabilities.rates = [16000]
bluez5.bap-server-capabilities.durations = [10]
bluez5.bap-server-capabilities.channels = [1, 2]
bluez5.bap-server-capabilities.framelen_min = 40
bluez5.bap-server-capabilities.framelen_max = 40
bluez5.bap-server-capabilities.max_frames = 2
The ladspa plugin uses `dlopen()`, etc. directly,
so add the `dl_lib` dependency. This is not necessary
in a new enough environment since newer glibc versions
have merged most things into libc.
For a BAP Broadcast Source endpoint, the QoS sync_factor enables the user
to adjust the Periodic Advertising interval based on the ISO interval
configured for the stream:
PA_Interval = sync_factor * ISO_Interval
Currently, this value is hardcoded to 2. This commit makes the sync_factor
configurable in the Wireplumber config file, along with the other config
parameters for BIGs.
