Make a new softVolume property that contains only the soft volume
to apply.
In the case of HW/SW volume, we pass the real volume in the
channelVolume and the leftover volume in softVolume. We don't
use the monitorVolume for this anymore because it is a completely
separate volume handled by the merger node.
This way, channelVolume always represents the effective volume
set on routes, channelmix and merger and only the softVolume (when
available) is applied as software volume by channelmix.
This makes things map a bit better to what is actually happening with
the real volume and leftover software volumes after applying the
hardware volumes in the device.
With this change, the volume on the monitor is not affected by the
sink volume anymore and we can use the monitorVolume for this later.
This also means that the monitor volume in pavucontrol of the sinks
does not change when the sink volume changes. PulseAudio is inconsistent
here: If the volume is HW, the monitor volume is not affected, if the
volume is SW, it is. In PipeWire there is an option in merger to
let the volume affect the monitor with monitor.channel-volumes = true.
This reverts commit 09106151d3.
We need the actual name and description of the mapping, not the
profile or else we end up with the full profile description in the
node description instead of the part of the profile that applies to
the device.
spa/plugins/alsa/acp/channelmap.h:466:9: warning: format not a string
literal and no format arguments [-Wformat-security]
466 | pa_snprintf(s, l, _("(invalid)"));
When the session becomes inactive (eg. user on active seat switched),
udev may make devices inaccessible. In this case, pipewire should give
up the devices and close their open file descriptors.
When we set the volume on a port, make sure we also set the save flag
so that the flag is put into the volume changed event and the session
manager can save it.
Fixes#995
Allocate up to the first 16 ports, use the last 2 ports and free the
first 14 ports.
This ensure our ports are not among the first ports so that port 128
and following are for normal apps, what is usually expected when
PipeWire is not running.
Fixes#951
The start-delay adds extra silence to the buffer before starting the
playback. The idea is to have more time to adapt to the device
startup and set the timer more accurately.
See #983, #431
When we are following the resampler requested size in capture, never
keep queued buffers around or we might get out of sync with the
requested size and cause cracks and pops in the resampler.
See #805
So that we can know if this node has routes or not.
Nodes without routes might need their volumes restored directly
with the node properties, like streams. Nodes with a route need their
volumes set on the device managing the node.
Remove the soft mute/volume events, add a new method to get the soft
volume and use the volume_changed event to emit the changed soft and
monitor (real) volumes event for the node.
Make sure the monitor ports always uses the monitor volume, which is the
real volume unaffected by the mixer volumes.
This configures the soft and real volume on the sink/source in all
cases and makes the monitor port follow the real volume of the sink.
See #897
errno should be set to the positive errno value.
This does not cause problems except for the pulse-server where the
errno value is negated and returned as an error result.
Make info parsing a bit easier to read by assigning the key and
value to temporary variables.
Improve the parsing of channelmap using json parser to make it
support more cases.
Add a unit test for channelmap parsing options.
Start with an extra period of silence.
Reconfigure a new timeout if we are too far off from the desired
buffer fill level. Reduce this level to the maximum error we
tollerate.
With this we use the extra period of silence to reconfigure the
timeout until we are close enough and we can start the dll with a
small error.
See #892
Pass the right value for the rate, we need to pass the graph rate.
Don't reduce bandwidth, it is not needed.
Fixes timings for reading the alsa-sequencer.
Don't try to move closer to the read/write pointers in the ringbuffer
to compensate for the resampler delay. We might not have enough time
anymore to complete a cycle without xruns. The delay is properly
reported in the clock times and should also be reported on the port
latency eventually.
For batch devices we want to keep the IRQ so that the pointers are
updated with the period-size. Brings my UMC404HD to 4.8ms roundtrip
times with IRQ at 6 sample and batch enabled.
When the quantum is changed, the error between the current and
expected buffer levels needs to be corrected with the quantum
difference.
For example, say we are running with a 1024 quantum and the quantum
is changed to 8192, when we wake up the filled level might be
1016 vs expected 8192, 1024 - 8192 = -7168. The real error for the
timeout was 1016 - 8192 - (-7168) = -8.
When we start or after an xrun, we need fill the buffer with one
period + headroom of samples, not period*2. This is because after
start we set our timeout immediately and expect there to be
period + headroom samples in the buffer.
With period*2 we take one period longer to start and we also feed
one period of error in the dll, which causes it to wobble for no
good reason.
Use the caps of the port to set the right flags on the new port.
We only want to put the terminal/physical flags on ports that look
like hardware ports. Port created by clients should not have this
flag.
Take the queued input samples into account when calculating the
required input size. This can be 0 when there is still enough
data queued in the input for another period.
Handle 0 read_size in alsa-source and make it push out a 0 buffer,
this will then drain the resampler and make it ask for a new buffer
size. This makes the transition from one period to another more
seamless for the resampler.
Fixes#805
Always reschedule the timeout based on the new quantum. If the
quantum descreased we want to wait some more until the buffer only
has the new quantum of samples left.
