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.
This property is exposed on the device Route and forwarded to the
nodes. It then configured the process_latency.ns field, which
influences the reported port latency.
This makes it possible to change the internal port latency on the
sink and source with pavucontrol and tweak the synchronization to
compensate for internal latencies in the device.
Use _alibpref to check if a device needs a UCM local config. Mark
the device as such and use this to set the OPEN_UCM property on
the device.
Open the UCM for a card when the device has the property set. Use the
same logic for loading the UCM as the acp code.
See #1251
UCM devices can require local data from use_case_mgr_open() but since
we do that in a separate process, make sure we reopen the use case
manager in case we are passed a UCM device so that the config is
available.
See #1251
When we add a new listener to an object, it will emit the full state
of the object. For this it temporarily sets the change_mask to all
changes. Restore the previous state after this or else we might not
emit the right change_mask for the next listener.
Consider the case where one there are two listeners on an object.
The object emits a change and the first listener wants to enumerate the
changed params. For this is adds a new listener and then triggers the
enumeration. If we set the change_mask to 0 after adding the listener,
the second listener would get a 0 change_mask and fail to update
its state.
This replaces the manual check for "true" and some (inconsistent) return value
of atoi. All those instances now require either "true" or "1" to parse as
true, any other value (including NULL) is boolean false.
