Exponentially increase the amount of time between smoother updates. We start
with a 2ms interval and increase up to 200ms intervals.
Smoother updates and the resulting linear regression take a fair amount of CPU
so we want to reduce the amount of updates.
- We now implement a logic where the sink maintains two distinct
volumes: the 'reference' volume which is shown to the users, and the
'real' volume, which is configured to the hardware. The latter is
configured to the max of all streams. Volume changes on sinks are
propagated back to the streams proportional to the reference volume
change. Volume changes on sink inputs are forwarded to the sink by
'pushing' the volume if necessary.
This renames the old 'virtual_volume' to 'real_volume'. The
'reference_volume' is now the one exposed to users.
By this logic the sink volume visible to the user, will always be the
"upper" boundary for everything that is played. Saved/restored stream
volumes are measured relative to this boundary, the factor here is
always < 1.0.
- introduce accuracy for sink volumes, similar to the accuracy we
already have for source volumes.
- other cleanups.
- drop the 'virtual_' prefix from s->virtual_volume since we don't
distuingish between reference and real volumes for sources
- introduce an accuracy for source volumes: if the hardware can control
the volume "close enough" don't necessarily adjust the rest in
software unless it is beyond a certain threshold. This should save a
little bit of CPU at the expensive of a bit of accuracy in volume
handling.
- other minor cleanups
This is a bigger change reworking a number of things:
- We now allow moving of the remap sink betwween backend sinks like any
other stream.
- We forward the fixed latency parameter of the underlying sinks the
same way as the dynamic latency.
This of course makes the name 'fixed' a bit of a misnomer. However the
definitions are now like this:
fixed latency: the latency may change during runtime, but is solely
controlled by the backend, the client has no influence.
dynamic latency: the latency may change during runtime, influenced by
the requests of the clients.
i.e. fixed vs. dynamic is from the perspective of the client.
We need to make sure that having both input and output weighs more for
selecting the default profile than a channel map that matches the
default channel map has.
https://bugzilla.redhat.com/show_bug.cgi?id=496320
This adds module-hal-detect-compat.c which when enabled will be compiled
into a module module-hal-detect which simply loads module-udev-detect.
The purpose of this is to allow easy upgrading without breaking
default.pa. Distributions are recommended to enable this to easy
upgrades from HAL versions of PA to udev versions.
Since Fedora does not enable OSS output support at all, but still uses
padsp, and in Gentoo we could also make use of padsp without OSS output
support, split the two things in two parameters, although they both check
for sys/soundcard.h once.
In some situations a rewind request travelling downstream might be
optimized away on its way and an upstream rewind processing might never
come back. Hence, call _process_rewind() before each _render()just to
make sure we processed them all.
