Don't increment the required activation count every time we change the
node prorties with a TRIGGER property. Only increment/decrement when the
value actually changed.
We are not allowed to call pipewire methods from any other thread than
the main thread so use invoke to schedule a module unload from the
pulseaudio thread.
Fixes some infinite loops when the work-queue list gets corrupted.
A driver node should use the target_duration and target_rate to adjust
the quantum and rate when the graph starts.
The camera nodes don't currently support any of this and simply enforce
a specific rate and duration for the graph clock. Mark this with a
FIXME. Otherwise, pipewire will complain that the node is ignoring the
configured graph rate.
We should really look at the graph target rate/quantum and only produce
a buffer when it is inside the current graph cycle. This would make it
possible to join audio and camera nodes and have them be in sync.
These drop-ins are not meant to be enabled by default, so let's move
them to fontconfig style *.conf.avail/ subfolders from which they can
be copied or symlinked to a location that will get merged into the
corresponding configuration file.
Signed-off-by: Niklāvs Koļesņikovs <89q1r14hd@relay.firefox.com>
Do transport release synchronously for simplicity. BlueZ handles
releasing while acquire is pending, but acquire while release is pending
would fail the acquire.
Otherwise we need to maintain an operation chain to handle trying to
acquire/release while the other operation is pending. This makes things
complex with little gained, as releases generally don't block for a long
time.
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>
Start and stop the timers in the data_loop. Otherwise we might be trying
to stop a timer while the data loop is starting it and we end up with
"ready non-active node" messages.
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.
Make NODE_NAME something that looks more like other node names.
Add MEDIA_NAME and NODE_DESCRIPTION.
Makes things look better in pw-top and the same in pavucontrol.
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.
The code that removes the mixer path if probing fails can be called in
the path that sets a non-off device profile on hotplug *before*
card->active_profile is updated, which results in spuriously removing
the mixer path. By this point, context->ucm->active_verb would be set
to the same as the profile name, so we can use that instead to avoid
the issue.
On Apple Silicon machines with the UCM profiles in the Asahi Linux repo,
this manifests as the headphones jack having hardware volume controls
*only* if PA is started with headphones connected and until they are
disconnected. Hotplugs end up triggering the bad codepath, and it falls
back to software volume (which is particularly a problem when the
hardware volume happens to be very low or 0 at that point).
Fixes: a9cc1373e2a7 ("alsa: ucm - update the mixer path also after volume probe")
Signed-off-by: Hector Martin <marcan@marcan.st>
The ucm_get_device_property() function adds to each UCM device's
playback_volumes (or capture_volumes) hash map an associated volume
mixer keyed with the UCM verb. These key-value pairs are then iterated
over in various places which assume the key is a profile name. This
assumption is no longer true since we can generate multiple profiles to
use conflicting devices.
A previous commit 45278904167f ("alsa-ucm: Stop conflating profile name
with UCM verb name") fixes some instances of this assumption, but misses
the relation explained above. Fix more instances of misleading
"profile"s where the UCM verb name is actually meant.
Fixes: 45278904167f ("alsa-ucm: Stop conflating profile name with UCM verb name")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Although it's a valid UCM configuration to have multiple devices using
the same PlaybackPCM or CapturePCM, it's unclear how PulseAudio should
handle the cases where multiple of these devices are enabled. Some
options I can think of are:
- Merge all devices sharing the same PCM into the same mapping, open
only one PCM substream for this mapping, and add 'combination ports'
that enable combinations of the devices. This has been the case until
recently, although the combination port logic was broken. A problem
with this is that we can't independently control device volumes. We
most likely cannot use hardware volumes either.
- Have one mapping for each device in the same profile, and open one PCM
substream for each mapping. This is the current state, and it fails
when there are fewer substreams than devices. Otherwise it works, but
it's still confusing, as sound directed to a device-specific mapping
might end up playing at multiple devices.
- Make multiple profiles each with combinations of upto-substream-count
devices, and have one mapping/substream per device. This still causes
the confusion mentioned above. And it's likely that the substream
count will almost always be one, where this case degenerates into the
last one.
- Have one mapping for each device in the same profile, but open only
one PCM substream. I assume this is possible with software mixing, but
it is still confusing like the above, and probably less performant.
- Generate multiple profiles each with one of the shared-PCM devices,
again with one mapping/substream for that one device. The trade-off
with this is that we can't use multiple of these devices at the same
time. However, this doesn't have the output device confusion,
combination port's volume problems, or the substream count limitation.
This patch takes a short-cut to achieve the last option, by considering
shared-PCM devices implicitly conflicting with each other.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
While switching profiles of the same UCM verb, existing code first
disables devices that are only on the first profile to avoid conflicts.
However, it only disables devices, not modifiers. Even worse, modifiers
which have PlaybackPCM/CapturePCM are incorrectly treated as devices and
result in a segmentation fault.
Check what we are disabling, and call the appropriate disable function
for both devices and modifiers. Modifiers are disabled before devices,
because _dismod calls fail when the modifier's supported devices are
disabled.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
These are mostly the same as the device helpers added in c83b34516929
("alsa-ucm: Add enable, disable, status helpers for devices"), but for
modifiers instead.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Looks like original intention was to scan over sample formats supported by PA,
but code does the scan by list of alsa formats. Reverse the map and adjust
fallback case which now can use the same map.
Perform detection of supported sample format and rates just after device is
opened, before `snd_pcm_hw_params()` is called for the first time. This fixes a
problem where device restricts available sample rates after HW params are set
preventing sample rate detection (seen with UAC2 devices and kernel 6.1.9)
