When api.alsa.split-enable=true for ACP device, instruct UCM to not
use alsa-lib plugins for SplitPCM devices.
Grab the information from UCM for the intended channel remapping, and
add the splitting information to the nodes emitted.
Session manager can then look at that, and load nodes to do the channel
splitting.
When the driver node is destroyed (like when unplugging the cable) it
will drop/pause all of the follower ALSA nodes. This is something that
happens internally because of how the ALSA nodes work together, on the
PipeWire level, the nodes are still running and they will just be moved to
another driver.
The problem is that nothing will then start the nodes again after moving
it to the new driver. Fix this by keeping track of the desired target
state of the ALSA node and restoring that state when we detect that we are
paused when moved to a new driver.
Fixes#4401
We can increase the MAX_LATENCY again if we increase the amount of
buffers when we are using a small buffer.
Normally we ask for 4 * quantum-limit as the buffer. This should be good
to use 1 buffer and quantum-limit as the quantum with enough headroom
to not run out of buffers.
If we are however using less buffer-frames we need to be careful and
allocate an extra buffer. Imagine using a buffer of 4096 frames, we can
support a quantum of up to 2048 frames if we use 2 buffers.
See #3744
It doesn't make sense to hang these on the data loop, so let's have
these on the main loop instead. Also avoids a potential crash while
removing them (since removal happens on the main loop and the data loop
might be polling while we're doing the remove).
When the device has not configured a format, remove the properties that
depend on the format so that they don't limit what we can configure the
device with next.
See #3613
The tag param has a list of arbitrary key/value pairs. Like the Latency
param, it travels up and downstream. Mixers will append the info
dictionaries or do some more fancy merging.
The purpose is to transport arbirary metadata, out-of-band, through the
graph and it's used for stream metadata and other stream properties.
There are currently several issues when multiple alsa devices are
involved.
For alsa devices that are followers, all data is written via
impl_node_process(). Currently spa_alsa_write() is only called if a new
buffer was queued.
It can happen that all buffers are in the ready list (queued by previous
calls but not yet written because there was no free space in the kernel
ring buffer). In this case writing stalls indefinitely.
To fix this, also call spa_alsa_write() if no new buffer is queued but
there are still buffers in the ready list.
If the ready list of the primary device is not empty then only this
device is handled because spa_alsa_write() is called directly. The other
devices make no progress during this interval.
The clock drift calculation works by comparing the alsa delay with the
expected delay since the last wakeup. This only work if the alsa
ringbuffer was filled completly. If the ready list contains a partial
buffer then the ringbuffer is not filled and the timing calculation
during the next wakeup is incorrect.
To fix all this, remove the special case for the non-empty ready list
and just call spa_node_call_ready() every time.
If we detect Playback/Capture Pitch 1000000, we can adjust those values
to update the feedback endpoint for the host. On the capture side, this
will instruct the host to adjust the rate at which data is being sent.
On the playback side, this will adjust the amount of data the USB gadget
driver sends out in each USB tick.
After we se the format, we negotiate the buffer size and period size.
When this fails, the period_size can be 0. Handle this case without
causing a floating point exception.
Use the NEAREST flag when setting a format. This only works for raw
formats and will update the format with the nearest accepted rate
or channels. We can then query the real configured format and use that
for the converter.
This makes things work when a driver tells us it can do 44100Hz but then
refuses and changes the rate to 48000.
See #2197, #2457, #2455, rhbz#2096193
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
Make the alignment parameter optional when negotiating buffers.
Default to a 16 bytes alignment and adjust for the max cpu
alignment.
Remove the useless align buffer parameter in plugins, we always
set it to 16 anyway.
The id is useless when dealing with props params, we need to use the
name of the property as the key. Also the id can clash with other ids
of other plugins.
Add PropInfo for all the params that we can configure at construct
time and also add them as PROP_params.
This way you can configure the headroom at runtime with this:
pw-cli s <id> Props '{ params = [ "api.alsa.headroom" 1024 ] }'
Expose the card object and always obtain one per pcm.
Keep the configured format in the card object.
Add a api.alsa.multi-rate property. When multi_rate is disabled,
only allow the last configured card rate on all PCMs.
This works around drivers that can't handle multiple samplerates
on their PCMs.
With this patch it should be mostly safe to configure multiple
sample rates in pipewire.conf
See #1547
Use the param user field to tag changes in the params.
codec changes emits an EnumFormat and Props change.
Accumulate various param changes and emit them together.
For hdmi and iec958 devices, enumerate the iec958 formats and
codecs. Initially only PCM is supported as a codec but with
a property or an init option, the list of codecs can be dynamically
configured.
