Filling a buffer with zeros to produce silence is wrong for
unsigned sample formats and compressed sample formats. This is
silence with an offset. A silent stream with unsigned or
compressed samples mixed with another stream produces a clipped
stream. To hear the problem start QEMU with
qemu-system-x86_64 -accel kvm -smp 4 -m 4096 \
-audiodev pa,id=audio0,out.mixing-engine=off \
-machine pc,pcspk-audiodev=audio0 \
-device ich9-intel-hda -device hda-duplex,audiodev=audio0 \
-boot d -cdrom Fedora-Workstation-Live-x86_64-37-1.7.iso
on a host configured to use PipeWire and start audio playback on
the guest HDA device.
PA_SAMPLE_U8 is the only unsigned PulseAudio sample format.
There is no need to care about unsigned multi-byte formats.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Drivers should only read the target_ values in the timeout, update the
timeout with the new duration and then update the position.
For the position we simply need to add the previous duration to the
position and then set the new duration + rate.
Otherwise, everything else should read the duration/rate and not use
the target_ values.
Place the target rate and duration in the io clock area.
The driver is meant to read these new values at the start of the cycle
and update the position rate and duration.
This used to be done by the pipewire server when it received the ready
callback from the driver but this is in fact too late. Most driver would
start processing and set the next timeout based on the old rate/duration
instead of the new pending ones.
There is still a fallback for the old behaviour (with a warning) when
the driver doesn't yet update the position.
Keep track of when a rate was forced on a driver and restore the
best rate again when no longer forced.
This handles:
- paplay playing a file at 44100Hz
--> driver openeing the device at 44100
- PIPEWIRE_PROPS='{ node.force-rate=48000 }' jack_simple_client
--> driver being forced to a new rate of 48000
- Stop jack_simple_client
--> Driver reverting back to 44100
Previously the driver would stay in 48000Hz until it idles.
This also works with pw-metadata -n settings 0 clock.force-rate 0.
Fixes#2133
When we already have a pending rate/quantum change, don't reconfigure
the driver.
This avoids going into an endless loop when:
1- paplay plays with 44100Hz on device1
2- jack_simple_client starts and attaches to device1
3- jack_simple_client links to device2
4- jack_simple_client is moved from device1 to device2, rate from
device1 is moved to device2 (44100Hz)
5- device2 becomes schedulable and sees the rate should be 48000Hz (the
default) it does a rate switch to 48KHz
6- jack_simple_client is suspended, links are back to init
7- jack_simple_client is moved back to device1
8- jack_simple_client links are activated and cycle restarts at 4
The cycle is broken because at 6 we avoid doing the suspend.
But instead ship config override files to enable it again.
The idea is that distros can make extra packages that can than be
installed to enable the upmixing.
Also ship a config file to enable more samplerates.
Fixes#3081
Emit both the bound_id and bound_props events from the protocol on
the core_resource.
Doing the dispatching of the bound_id/bound_props in the core to the
proxy doesn't handle the case where the client has a listener directly
on the core_resource.
Fixes#3109
this event extends the bound_id event and sends the global properties as
well.
This can be used to get the object.serial, for example.
It can also be used in the future to let the server generate unique
property values, like the node.name, and let the client know about the
new property value.
Fix Digest, we need to use the method to generate a new Digest for each
request.
Use newer openssl methods instead of deprecated ones. The RSA sign still
need to be ported.
