Report the "fractional" part of the resampler delay in
spa_io_rate_match::delay_frac, in nanosamples (1/1e9 sample) at node
rate.
The delay values are best reported in units where it is clear what the
clock domain is, so report the value in fractional samples instead of
nanoseconds. Conversion to ns is also just dividision by the appropriate
rate.
Resampler without prefill was sometime outputting with different delay
than with prefill. Adjust initial history by 1 which seems to bring it
more in line.
The resampler phase also appears to depend on how many samples remain in
history which leads to possibly unexpected +-1 variation. Take this into
account in reported phase.
These changes make the resampler delay tests pass.
Both changes are sort of empirical --- I don't fully understand why
these would fix things but they seem to be needed to make the delay
calculations agree with what the resampler outputs.
When we do any other blocking in the render function, we should unblock
and call _wait_preroll() when we go to PAUSED.
We can have this situation when all the buffers are queued in the
pw_stream and we get a new _render() call. We can't get more buffers
from the pool and so we must block and wait. When we go to PAUSED we
need to unlock and go to _wait_preroll(). Implement this by setting a
pool paused flag that is set when the sink goes to paused, we can then
return a special value that does the wait_preroll().
See !2248
Setting bufferpool to flushing state in PAUSED state is preventing the
buffer flow if there is a seek/flush event.
Instead, set the bufferpool to flushing during the `flush-start` event
and clear it during the `flush-stop`
Deactivate/activate the stream during flush event only if the sink is
in the PLAYING state. In the PAUSED or READY state, the stream would be
inactive and we do not want to alter that
When we write samples, check if we make a jump in the ringbuffer and
clear the samples we jumped over.
If we don't do this, the reader side might pick up old samples that we
didn't write or clear but that are now available for reading after we
made a jump in the ringbuffer.
This migh not be exactly what pulseaudio does but it is good for now.
Fixes#4464
flush the pw buffers to the stream's queue during a FLUSH_START event
and return the unqueued pw buffers, if they are dropped/released without
being rendered, so they can be available to be dequeued for the subsequent
`acquire` calls
The delay is always expressed in samples at the output rate of the
resampler. For input streams we need to convert this to the expected
input rate.
Make the delay reporting in playback streams more accurate.
We now automatically move non-rt clients into non-rt threads so the
client-rt.conf is obsolete.
Move the module-rt in client.conf and add conditions to disable modules.
Transparently load client.conf in case applications still specify
client-rt.conf.
Custon configuration in the client-rt.conf.d/ should be moved to
client.conf.d/
The resampler delay was off by one sample, so remove the corresponding
fudge factor here. This matters for BAP output synchronization.
The resampler has also some fractional delay, so there can still be
sub-sample offset between the original and resampled timelines. This is
not currently taken into account.
Resampler delay for N taps is N/2-1 input samples.
Add test that checks this.
When input rate is varying, the resampler also accumulates additional
sub-sample delay. The resampler does not currently have API to report
the instantaneous sub-sample delay. Add knownfail test for it.
Wireplumber and other system services use local real time timestamps in
logging, so it's more convenient if also PW uses them.
Add env var for selecting the timestamp type, default to "local".
In timestamps, support different clocks and local time as formats.
Local real time timestamps are useful when trying to correlate logs from
different sources.
When setting Route param, check that the route actually is part of the
active profile.
Also, check that the device given corresponds to the given route, before
setting properties. acp_device_set_port() also checks this, but we
shouldn't allow updating properties of Routes in non-active profiles.
Setting ports or applying props on devices not part of the profile can
do unexpected things e.g. alter mixer settings.
Don't mix endpoint and transport paths, they're generally different.
If ASHA transport already existed, free the old one but not the device,
as the ASHA device existence should track how it appears in DBus.
G722 codec id for ASHA is chosen arbitrarily to be different from
A2DP and BAP codec IDs. ASHA spec does not specify a codec ID like
A2DP/BAP.
In places where codec_id comparisons are done, ensure that the check
is done against the codec of the right type viz. A2DP/BAP/ASHA.
Copy the server value to the context so that the locally allocated
buffers match the server quantum-limit and we don't cause xruns because
of too small buffers.
See #4490
Make sure we only make the buffer for the follower larger when we
downsample because then we need to ask for more data from the follower
to fill up a quantum.
Never try to make the follower buffer smaller than the quantum limit.
The reason is that the graph rate could be decreased dynamically and
then we would end up with too small buffers.
See #4490
Load multiple graphs with audioconvert.filter-graph.N where N is the
order where the graph is inserted/replaced. Run the graphs before the
channelmixer.
Graphs can be added and removed at runtime.
Instead of recalculating what to do every cycle, we can prepare a
static schedule and just run that. We only need to reevaluate it when
something changes.
For input streams, first run the resampler and then the channelmix. This
ensures that the channelmix is run with the rate of the graph instead
of the rate of the input. This is nicer because rate and quantum align
with the graph and the sample accurate volume ramps will work as
intended.
For output streams, leave the resampler after the channelmix for the same
reasons.
