As part of this, in alsa-udev.c, certain structures and variables referred
to as "device" are renamed to "card". Otherwise, there is ambiguity, since
"device" can mean a udev device, an SPA device, a compress-offload device,
a PCM device etc.
Also, replace "card id" with "card number" to emphasize that these integers
are not actually SPA object IDs.
We're missing the delay in samples plus all of the extra samples of
silence we use to restart the device. This is in the samplerate of
the device.
Convert this to the time domain of the graph before adding it to xrun.
The isinf function returns -1 for negative infinity on glibc, but
the standard guarantees no such behavior (e.g. in C++ it always
returns a bool, on musl libc it's a macro that expands to a bool
expression), saying just that it returns a non-zero value.
This was added in pulseaudio around 15 years ago, and was never
fixed; pipewire then got the code from it. However, we can portably
check against -INFINITY instead (from math.h, already included).
Ref 045c1d6
The default period is based on the default rate and might be too small
when using high samplerates. Scale the rate with the samplerate and make
sure it's a power of 2 to avoid trouble.
Fixes#3444
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.
Add an xrun counter in the clock that accumulated the duration of
xruns. Fill this in in alsa-pcm.
A client could use this to dectect xruns (when it changes) and to align
the position and nsec after an xrun.
It is sometimes useful to add a custom profile-set.
For that, e.g. `default.conf` needs to be modified.
(at least, i have not succeeded in just adding a new file)
But that change gets overridden when the package is updated,
which could be *extremely* dangerous, e.g. if said profile
changed the `volume-limit`.
By shipping an "empty" `9999-custom.conf`,
the update becomes less problematic,
because one can now use e.g. `dpkg-divert` on said file.
Refs. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050293
Only update the avail when we did a snd_pcm_forward(). Otherwise
we might think there is more available than there really is and we
might get xrun.
See #3395
It seems there are drivers that don't return a good values and we end up
with a lot of delay or automatic disable of htimestamp when the values
look too off.
Always use get_avail() and then only fetch the hires timestamp when
enabled to enhance the delay reporting. This way we also recover from
errors from snd_pcm_avail() instead of ignoring them.
This should make the recover after mmap_begin obsolete but we'll leave
that just to be safe.
Since UCM doesn't perform the path lookups of alsa-mixer all UCM devices
fall back to the card's properties for e.g. icons and hence usually show
the `audio-card` icon for all ports giving a confusing UI to users as
all ports show the same icon.
As ucm names are pretty standard augment some common port names with
icons.
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.
Use snd_pcm_htimestamp to get both the available space and the timestamp
when this was calculated. We can then use this to get a better estimate
of the delay in the device against the graph start and get a more
reliable delay between capture and playback.
Use separate values for the number of available samples in the
ringbuffer and the delay in the device.
When using htimestamp we can use the tstamp to get a more accurate delay
value against the graph start time.
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 a separate variable to hold the maximum amount of drift we allow
between driver and follower. Ensure this value is smaller than the max_error
and period size so that we have at most 1 period of drift.
