The configured adjust time does not match exactly the real adjust time. Also
the adjust time varies. To improve latency estimation use an average of the
measured adjust times instead of the configured value in all calculations.
Setting the allow_negative flag of pa_{source,sink}_get_latency_within_thread() to true
leads to improved end to end latency estimation and to correct handling of negative port
latency offsets.
The reported latency of source or sink is based on measured initial conditions.
If the conditions contain an error, the estimated latency values may become negative.
This does not indicate that the latency is indeed negative but can be considered
merely an offset error. The current get_latency_in_thread() calls and the
implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative
latencies because they do not make sense from a physical point of view. In fact,
the values are truncated twice, once in the message handler and a second time in
the pa_{source,sink}_get_latency_within_thread() call itself.
This leads to two problems for the latency controller within module-loopback:
- Truncating leads to discontinuities in the latency reports which then trigger
unwanted end to end latency corrections.
- If a large negative port latency offsets is set, the reported latency is always 0,
making it impossible to control the end to end latency at all.
This patch is a pre-condition for solving these problems.
It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow
negative return values. Truncating is also removed in all implementations of the
PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag
is set to false for all calls of pa_{sink,source}_get_latency_within_thread()
except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the
original behavior is not altered in most cases. Only if a positive latency offset
is set and the message returns a negative value, the reported latency is smaller
because the values are not truncated twice.
Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread()
for monitor sources because the source gets the data before it is played.
The latency controller will try to adjust to the configured latency regardless
of underruns. If the configured latency is set too small, it will lead to
periodically occuring underruns. Therefore an underrun protection is implemented
which will increase the target latency if too many underruns are detected.
Underruns are tracked and if more than 3 underruns occur, the target latency
is increased in increments of 5 ms. One underrun per hour is accepted.
The protection ensures, that independent from the configured latency the
module will converge to a stable latency if the configured latency is too
small.
The print_msg argument to update_minimum_latency() had to be re-introduced,
because there is one place where the message should not be logged.
If source or sink are changed, the current sink input rate may be different
from the default rate. Switch sink input rate back to default to avoid the
influence of the previous combination of source and sink.
The previous patch assumed constant port latency offsets. The offsets can
however be changed by the user, therefore these changes need to be tracked
as well. This patch adds the necessary hooks.
Also the print_msg argument was removed from update_minimum_latency() and
update_latency_boundaries() because the message should always be logged.
With the current code, the user can request any end-to-end latency. Because there
is no protection against underruns, setting the latency too small will result in
repetitive underruns.
This patch tries to mitigate the problem by calculating the minimum possible latency
for the current combination of source and sink. The actual calculation has been put
in a separate function so it can easily be changed. To keep the values up to date,
changes in the latency ranges have to be tracked.
The calculated minimum latency is used to limit the configured latency.
The minimum latency is only a "best guess", so the actual minimum may be much
larger (for example for USB devices) or much smaller than the calculated value.
Changes of the port latency offsets are not yet handled, this will be done in a
separate patch.
When moving from a user suspended source or sink to an idle suspended source or sink
the sink input or source output would not be uncorked because we did not check for
the suspend cause.
Uncorking also would not be possible in that situation because the state change callback
of the source output or sink input is called before the new source or sink is attached,
leading to a crash of pulseaudio due to a cork() call without valid source or sink.
The previous patch fixes this problem, therefore sink input or source output can now also
be uncorked when the destination is idle suspended.
If pa_sink_input_cork() or pa_source_output_cork() were called without a sink
or source attached, the calls would crash pulseaudio.
This patch fixes the problem, so that a source output or sink input can still
be corked or uncorked while source or sink are invalid. This is needed to
correct the corking logic in module-loopback.
The previous commit, "loopback: Initialize latency at startup and during
source/sink changes", was an old version of the patch that got
accidentally pushed instead of the last version. This commit does the
changes that were omitted when applying the old patch.
The current code does not make any attempt to initialize the end-to-end latency
to a value near the desired latency. This leads to underruns at startup because
the memblockq is initially empty and to very long adjustment times for long
latencies because the end-to-end latency at startup is significantly shorter
than the desired value.
This patch initializes the memblockq at startup and during source or sink changes
so that the end-to-end latency will be near the configured value. It also ensures
that there are no underruns if the source is slow to start and that the latency
does not grow too much when the sink is slow to start by adjusting the length of
the memblockq until the source has called push for the first time and the sink
has called pop for the second time. Waiting for the second pop is necessary
because the sink has not been started when the first pop is called.
For clarity, variables have been separated into input, output and main thread
variables.
Bug 96741 shows a case where an assertion is hit, because
pa_asyncq_new() failed due to running out of file descriptors.
pa_asyncq_new() is used in only one place (not counting the call in
asyncq-test): pa_asyncmsgq_new(). Now pa_asyncmsgq_new() can fail too,
which requires error handling in many places. One of those places is
pa_thread_mq_init(), which can now fail too, and that needs additional
error handling in many more places. Luckily there weren't any places
where adding better error handling wouldn't have been easy, so there are
many changes in this patch, but they are not complicated.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96741
Replace the current latency controller with a modified P-controller. For
better readability separate the controller function. For small latency
differences, the controller forms a classical P-controller while it saturates
at 1% deviation from the base rate for large latency differences.
After switching source or sink, call adjust_rates after a third of a second
instead of waiting one full adjust time. This will ensure that latency regulation
starts as soon as possible.
Restaring the timer and obtaining the latency snapshots belong to the timer callback.
To maintain an adjust time as near as possible to the configured value, the timer is
now restarted immediately at the beginning of the timer callback.
To improve the overall latency estimation, the delay between the two snapshots
is taken into account. To minimize the snapshot delay, the order of the snapshots
is reverted. Additionally the latency at the base rate is calculated. It will be
used later as the input to the latency controller.
The delay and render memblockq are using the source and sink sample specs,
so using pa_bytes_to_usec() will produce better estimates of the delays than
using pa_resmpler_result(). Because the delays are considered to be part of
the sink or source latency, they are added to them. source_output_buffer
becomes obsolete.
This saves some proplist allocations and a couple of code lines. Also,
logging is better, because the set_property() functions work with
string values, while the update_proplist() functions assume opaque
binary data, and therefore can't log the property values.
Originally pointed out by Georg Chini.
Calculating buffer = buffer + (send_counter - recv_counter)
in one branch and buffer = 2 * buffer - (recv_counter - send_counter)
looks very obviously wrong. In other words, before the patch, the
contribution from the previous lines was double-counted.
Message id 0 is PA_SOURCE_OUTPUT_MESSAGE_GET_LATENCY. So, every time PulseAudio
sent PA_SOURCE_OUTPUT_MESSAGE_GET_LATENCY message to the loopback source output,
it actually hit the SOURCE_OUTPUT_MESSAGE_LATENCY_SNAPSHOT handler instead. As a
result, the SOURCE_OUTPUT_MESSAGE_LATENCY_SNAPSHOT handler was called when not
intended, the default PA_SOURCE_OUTPUT_MESSAGE_GET_LATENCY handler was not called
at all, and the latency was thus evaluated incorrectly.
Reported-by: Georg Chini <georg@chini.tk>
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
During my work on module-loopback I found a bug that sometimes crashes pulse when
module-loopback is loaded due to pushing a zero-length block into the memblockq.
As there is a one-line fix I thought you might want it for 6.0.
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
Currently the biggest possible sink latency is 10 seconds. The total
latency of the loopback is divided evenly for the source, an
intermediate buffer and the sink, so if I want to test 10 s sink
latency, the total needs to be three times that, i.e. 30 seconds.
The source output and sink inputs should be corked if the corresponding
sink/source is suspended, as handled during module initialization. This
also needs to be handled during stream move, because the suspend state
of the destination sink/source might be different to the previous one.
This fixes the issue with an infinite number of "Requesting rewind due
to end of underrun" traces after a stream move.
This patch removes all tabs hidden inside the source tree and replaces
them with 4 spaces.
Command used for this:
find . -type d \( -name bluetooth \) -prune -o
-regex '\(.*\.[hc]\|.*\.cc\)' -a -not -name 'reserve*.[ch]'
-a -not -name 'gnt*.h' -a -not -name 'adrian*'
-exec sed -i -e 's/\t/ /g' {} \;
The excluded files are mirrored files from external sources containing
tabs.
u->asyncmsg is accessed from two IO threads. teardown() shouldn't
flush the queue from the main thread while both IO threads are still
potentially using the queue. This patch fixes that error by flushing
the queue from the sink input thread when the sink input is being
unlinked.
Flushing the queue in teardown() caused this assertion in
pa_asyncmsgq_get() to crash sometimes: pa_assert(!a->current)
The sink input may_move_to() callbacks can be called while the source
output is not connected to any source (i.e. is currently moving too),
and vice versa.
Thanks to Frédéric Dalleau for reporting this bug.
Once the sink input has been routed in pa_sink_input_new(),
the sample spec and channel map have already become fixed.
The sink input and source output must use the same stream
format, because the data is copied as-is.
When module-loopback is loaded without arguments, the ss and
map variables are initialized with dummy values. This caused
a problem, because also pa_memblockq_new() was called with
the dummy values, making it work incorrectly. The base was
set to 1 instead of the real frame size, which in turn
caused alignment related crashes.
During initialization, the approach avoids having a needless short
period of corked state in case the sink is suspended, by always creating
the source-output corked and uncorking it immediately afterwards when
the sink is not suspended.
During initialization, the approach avoids having a needless short
period of corked state in case the source is suspended, by always
creating the sink-input corked and uncorking it immediately afterwards
when the source is not suspended.
At module-loopback load, if no sink is given, the default sink is used. If the
stream has a media.role property, the property cannot be used because a the
source or sink is forced to default. Both module-intended-roles and
module-device-manager are affected. The same apply to sources.
With this patch, if sink or source is missing, routing modules can be used.
Make sure we can't be called into by remaining references to
sink-inputs and source-outputs after we have unloaded, as
that will likely lead to segfaults.
Thanks to Tanu for providing valuable input on this patch.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Calling adjust_rates after teardown results in segfault, and
judging from the Ubuntu bug report, this can happen.
Actively prevent this by destroying the time event, and by
setting adjust_time to 0, we also prevent this routine being
called on max request update.
BugLink: https://bugs.launchpad.net/bugs/946400
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Flush the message queue before tearing down, and dest==NULL is valid in case moving failed.
With this my module-loopback finally no longer causes frequent crashes.
These are not used for anything at this point, but this
makes it easy to add ad-hoc debug prints that show the
memblockq name and to convert between bytes and usecs.
