Instead of returning the dummy empty buffer.
The dummy buffer is problematic in various ways:
1) it has a fixed hardcoded size and doesn't adapt to the quantum_limit.
2) when used as output buffer, data is written to the void with no
indication for the application.
3) using random data as an input buffer is going to cause unexpected
noise with no indication to the application.
Make it possible to change the quantum-limit in the config file past
8192 up to 65536. This will make all plugins allocate larger buffers
so that the quantum can be increased to larger values as well,
This is interesting when dealing with higher sample rates where the
8192 sample limit will cause wakeups every 20ms at 384KHz.
See #1931
Allow an app to request up to 2048/48000 quantum. This will be scaled
with the selected sample rate so if the graph changes to 96000, the
quantum will be scaled to 4096. It will scale up to the hard limit of
quantum_limit.
See #1931
Parse the quantum_limit parameters and use this to scale the buffers so
that they can contain the maximum allowed samples instead of the
hardcoded 8192 value.
See #1931
Also scale the max_quantum with the selected rate. Add a new
quantum_limit property that is the upper limit of the quantum regardless
of the sample rate, this is usually the allocated buffer size.
See #1931
Ignore latency params on the monitor ports of merger. They interfere
with the latency reporting set by the adapter.
The adapter will set the latency param from the follower on port 0 in
the converter, so pass this on to the merger as the latency and ignore
all other updates.
Fixes a case where the latency of a sink would become 0 when a monitor
port was recorded from.
We take half of the current quantum as the period size for batch
devices. Limit this to the default quantum to ensure we don't end up
with too much headroom.
Based on patch from Barnabás Pőcze <pobrn@protonmail.com>
Instead of trying to keep track of the missing bytes ourselves, use the
simple tlength - avail - requested formula to request more bytes from
the client.
Fixes#1981
Double device profile timeout to 6sec.
In some cases, BlueZ can take more than the previous 3sec to connect all
profiles. It's better to wait for a bit longer, so that devices have all
profiles visible already when they first appear.
This works around issues in Wireplumber profile selection logic.
Don't require all device profiles to be connected before marking the
device as connected before profile timeout. Show device already when all
A2DP/HSP/HFP profiles for sink/source direction have connected.
There are devices that in principle can have both sink/source profiles
present, but cannot operate both directions at the same time. In case
profiles come online later, the only effect is that the device profiles
will get an update after the device is published.
The pulseaudio pa_ato* functions set errno and return -1, when the
number cannot be parsed.
Some parts of parsing the profile files (e.g. parse_eld_device) rely on
these functions returning errors when the input is not a number.
Remember what we last returned from jack_get_buffer_size and only
emit a buffersize change event when somwthing new is configured.
Fixes startup of jconvolver.
Fixes#1989
pipewire-jack/src/meson.build:
Add the custom `jack_implementation=pipewire` pkgconfig variable to the
generated jack.pc file to be able to distinguish jack implementations.
As jack implementations exist with jack1, jack2 and pipewire-jack, it is
not (easily) possible to distinguish them by looking at the version
alone (particularly the case with jack2 vs. pipewire-jack, as they share
the same headers).
Related to #1666
When creating a new build directory, Meson prints a warning:
WARNING: Project specifies a minimum meson_version '>= 0.56.0' but
uses features which were added in newer versions:
* 0.59.0: {'unescaped_variables arg in pkgconfig.generate'}
Since 0.59.0 was released a while ago and no one has complained so far,
it should be reasonable to just bump the minimum version required,
rather than try to make it 0.56.0 compliant.
When the follower has no param to enumerate we would keep on enumerating
the params of the converter forever. Fix this by setting the next value
to something that would then stop the iteration.
Also increase the amount of bits for the follower because it might need
them.
