This should make it easier for clients to elevate their audio threads to
real time priority without having to dig through much through specific
system internals.
This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
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.
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
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.
Commit fa092af59c removed an argument to pa_rtpoll_run, but
forgot to remove that argument for all callers to pa_rtpoll_run.
This commit removes the remaining ones.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
I think this makes the code a bit nicer to read and write. This also
reduces the chances of off-by-one errors when checking the bounds of
channel count values.
Changes since v1:
Use max value of jack_port_get_latency_range to calculate the latency
and squash compiler warnings cased by using jack_port_get_total_latency
Modifying latency only works inside a callback, and for hardware the
latency is generally fixed on jack, so just take the max value.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Just picking up a crash report from Ubuntu, here's the result.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 934c52c79bb6faed56a64d6e15f9b285f687afee Mon Sep 17 00:00:00 2001
From: David Henningsson <david.henningsson@canonical.com>
Date: Mon, 28 Mar 2011 14:30:44 +0200
Subject: [PATCH] module-jack-sink/source: protect against null return in jack_get_ports
According to jack_get_ports documentation, it seems like returning NULL
is valid, and that it should be freed using jack_free.
Reported-by: Grayson Peddie
BugLink: http://bugs.launchpad.net/bugs/733424
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
