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
This fixes a crash. sink_input_pop_cb() drains the message queue that receives
memchunks from the combine sink thread to avoid requesting more audio too soon.
The same message queue received also SET_REQUESTED_LATENCY messages, which
generate rewind requests. Rewind requests shouldn't be issued in the pop()
callback, doing so results in an assertion error. Therefore, it was not safe to
drain the message queue in the pop() callback, but usually the queue is empty,
so this bug was not immediately detected.
This patch splits the message queue into two queues: audio_inq and control_inq.
audio_inq receives only messages containing memchunks, and control_inq receives
only the SET_REQUESTED_LATENCY messages. The pop() callback only drains the
audio queue, which avoids the rewind requests in the pop() callback.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90489
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.
to print a pa_usec_t, the format specifier to use is "%" PRIu64
modules/module-combine-sink.c: In function 'update_latency_range':
modules/module-combine-sink.c:750:5: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'pa_usec_t' [-Wformat]
modules/module-combine-sink.c:750:5: warning: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'pa_usec_t' [-Wformat]
to print a size_t, use %zu
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
block_usec should be determined by the sink max latency, not the other
way around. This change doesn't cause any change in behaviour, but
makes the code more logical. Further updates to block_usec are already
done correctly, so this is the only place that needs modification.
Mark the sink as DYNAMIC_LATENCY and implement update_sink_latency_range
on its sink-input to collect the combined latency range of all sinks.
Implement update_requested_latency on the sink to configure the final
latency by combining the sink-input requested latencies. This makes us
honour the client latency request.
Also add more debug log.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=47899
Add the output from its sink-input attached callback and remove it
again from the detach callback. This simplifies some output_enable
and we can also avoid posting 2 messages for the sink.
A value of 0 for adjust_time should disable rate adjustment.
Fix a bug where a 0 value causes rate adjustment to be called
continuously instead after an unsuspend event.
The outputs are removed from the idxset before output_free() is
called. Trying to remove them again in output_free(), and asserting
that it should succeed caused crashing whenever outputs were freed.
This bug was introduced in commit
061878b5a4.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=65901
Since some devices can be chatty with regards to how often they return
from poll(), this adds a PA_UNLIKELY() to all the the rewind_requested
checks in our sink modules to make the general case (no rewind was
requested) the fast path.
When a rewind is requested on a sink input, the request parameters are
stored in the pa_sink_input struct. The parameters are reset during
rewind processing, and if the sink decides to ignore the rewind
request due to being suspended, stale parameters are left in
pa_sink_input. It's particularly problematic if the rewrite_bytes
parameter is left at -1, because that will prevent all future rewind
processing on that sink input. So, in order to avoid stale parameters,
every rewind request needs to be processed, even if the sink is
suspended.
Reported-by: Uoti Urpala
Previously thread_func() used PA_SINK_IS_OPENED() to check whether
some data should be rendered. process_render_null() used a different
check: it would return immediately if the sink was not in the RUNNING
state. This caused a busy loop when the sink was in the IDLE state,
because process_render_null() didn't update the timestamp, and
thread_func() still kept the timer active using the old timestamp.
pa_rtpoll_run() would return immediately because of the old timestamp.
This is fixed by using the same check in both thread_func() and
process_render_null(). Since the checks are the same, it's actually
redundant to have the check in process_render_null(), so it is now an
assertion.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=54779
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.
The smoother is paused on initialization and resumed when the sink
state is set to running. Otherwise, early latency estimates are
too low since there is some delay between module initialization and
entering the running state.
After the smoother is initially resumed, it is paused when the sink
state is not running. The previous behavior was to pause only when
the sink enters suspended state, however, this would lead to large
errors in latency estimates after the sink has been idle for some
time.
This is the beginning of work to support compressed formats natively in
PulseAudio. This adds a pa_stream_new_extended() that takes a format
structure, sends it to the server (=> protocol extension) and has the
server negotiate with the appropropriate sink to figure out what format
it should use.
This is work in progress, and works only with PCM streams. Actual
compressed format support in some sink needs to be implemented, and
extensive testing is required.
More details on how this is supposed to work is available at:
http://pulseaudio.org/wiki/PassthroughSupport
