When the PCM is stopped, don't check for early wakeup because if we
are early, we will never be on time in the next iteration either because the
PCM is stopped and doesn't advance.
Also don't try to align when stopped.
See #3565
Add an option to automatically use snd_pcm_link when the follower clock
is matching the driver. Only set this to true in pro-audio and when
nodes are scheduled together.
See #3556
We only start the ALSA pcm after we get our first buffer.
We still need to do the sync through (and get the number of prefilled
samples) to make sure we set our new timeout and don't keep on waking
up quickly while the graph fetches the first buffer.
Rename some variables to make it clear that we are dealing with the rate
and duration of the driver.
Set the driver rate in the clock instead of the target_rate, which we
might have rejected.
When we are using the same clock (!matching) try to link the two PCM
devices together. This starts and stops the devices at the same time and
gives better latency.
Keep track or the follower state and do the sync from the driver
wakeup.
This improves sync between devices because the sync no longer
depends on when the node was woken up in the graph and scheduled. We
would have been able to handle this difference by using the htimestamp
but that doesn't seen to work reliably on some hardware.
This is also essential for the interrupt based scheduling.
Split the spa_alsa_start() in a prepare and start function. Prepare
will then also reset state and prefill the playback buffer with silence.
This makes it possible to reuse the prepare function in recover().
The threshold depends on the samplerate and even when the graph rate or
quantum didn't change, the driver could be opened in a different
samplerate, which would cause the timeouts to be wrong and cause xruns.
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 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
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.
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.
