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.
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.
Don't reschedule a timeout when we have less samples available than the
target but only reschedule when we have less that the required amount we
need to read. This ensures that we hover around the target level and the
timeouts/rate matching adapts correctly. Previously we would only rate
match if the have at least the target amount of samples, which would
then always result in a possitive rate adjustment and cause drift.
For capture, make sure that there is at least 32 samples of headroom
when we are not using IRQ mode to handle jitter in the timer wakeup.
For capture of batch devices this results in (for a 1024 quantum) a
target buffer fill level of 1024 + 512, and we will read if there are at
least 1024 samples available.
For non-batch devices we aim for a target buffer fill level of 1024 + 32
and read if there are at least 1024 samples available.
For IRQ based scheduling we might otherwise be woken up after we only
added one of the fds to the poll loop and then we get an error when we
try to update it afterwards. Instead, add the fds from the data thread
to get things nicely in sync.
In IRQ mode, disable the ALSA fds while we wait for the graph to produce
data. Otherwise we will wake up very quickly over and over.
When we get more data, we activate the sources again to start the next
cycle.
Provides configuration to disable timer-based scheduling. This can be
useful at low latencies, for example, where period-based interrupts
might be more reliable than timers.
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.
Don't just limit the max delay of samples we keep in the ALSA ringbuffer
to the buffer_size but to half of it. Make this into a max_delay
variable.
If we have a buffer size of 8192 samples and a headroom of 8192 samples,
when capturing, we would wait for the ringbuffer to contain at least
8192 samples, which would always xrun. When we limit the size to
half, we can still read the data without xruns.
Fixes#2972
When we are rate matching, keep some more headroom to make sure we
have enough data for the adaptive resampler.
Fixes crackling when following the dummy node and probably also when
following another capture device.
Add SPA_SCALE32_UP that scales a uint32 without overflow.
Use this for scaling the threshold in ALSA.
Fix the scaling in audioconvert of the buffer size, the scaling was
wrong and it was also causing an overflow resulting in choppy sound in
some cases.
See #2680
For encoded format, we need to send bigger chunks to make the encoder
happy. Add a new min_delay variable with this info so that we never
leave less than that amount of samples in the ringbuffer.
Fixes#2650
When reading the timerfd gives an error, we should return right away
because the timeout did not happen.
If we change the timerfd timeout before reading it, we can get -EAGAIN.
Don't log an error in that case but wait for the new timeout.
When we try to play data but the ringbuffer is full, we need to start
the device or else we will stay in this situation forever and stay
silent.
Fixes#2830
Do not start the playback device until there is data to play. Otherwise
time consuming configuration of other nodes (such as setting hw params
of a capture device) may be done after playback has been started, which
may cause xrun.
uint32_t i;
for (i = 0; i < SPA_N_ELEMENTS(some_array); i++)
.. stuff with some_array[i].foo ...
becomes:
SPA_FOR_EACH_ELEMENT_VAR(some_array, p)
.. stuff with p->foo ..
DSD64 would be a rate of 44100 * 64 / 8. When packed in U32_BE, we would
negotiate 44100 * 8 / 4 (88200) with the device, this means all rates
from 88200 and up are allowed for DSD64 in U32_BE.
When the device is not running but has a format, close/open the
device to get all the available formats again. Do the same when
setting a format.
Otherwise, the configuration space of the device is restricted to the
current negotiated format and we can't query the other possibilities
or change it.
Fixes#2625
We need to check the last offset against the size of the buffer, not the
remaining size in the buffer.
When the writing is split, this could cause the buffer to be reused
wrongly.
See #2536
