Attachment 117188 Details for Bug 91370 – tunnel-sink-new: don't force latency limit

[patch] tunnel-sink-new: don't force latency limit

0001-tunnel-sink-new-don-t-force-latency-limit.patch (text/plain), 3.42 KB, created by Pierre Ossman on 2015-07-17 08:47:23 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Pierre Ossman

Created: 2015-07-17 08:47:23 UTC

Size: 3.42 KB

patch

obsolete

>From f53313f3013e2d27892a2c5b291c538587ed69c8 Mon Sep 17 00:00:00 2001
>From: Pierre Ossman <ossman@cendio.se>
>Date: Fri, 17 Jul 2015 10:35:55 +0200
>Subject: [PATCH 1/3] tunnel-sink-new: don't force latency limit
>
>Pick a more sensible default instead of artificually limiting the
>upper bound on the latency. Also make it clear that this is just
>because we don't have rewind support.
>
>Signed-off-by: Pierre Ossman <ossman@cendio.se>
>---
> src/modules/module-tunnel-sink-new.c | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
>diff --git a/src/modules/module-tunnel-sink-new.c b/src/modules/module-tunnel-sink-new.c
>index 8c6b56a..c9be85b 100644
>--- a/src/modules/module-tunnel-sink-new.c
>+++ b/src/modules/module-tunnel-sink-new.c
>@@ -59,7 +59,9 @@ PA_MODULE_USAGE(
>         "cookie=<cookie file path>"
>         );
> 
>-#define MAX_LATENCY_USEC (200 * PA_USEC_PER_MSEC)
>+/* FIXME: Default latency to use until we have proper rewind support.
>+ *        Probably best to keep this in sync with DEFAULT_FIXED_LATENCY. */
>+#define DEFAULT_LATENCY_USEC (250*PA_USEC_PER_MSEC)
> #define TUNNEL_THREAD_FAILED_MAINLOOP 1
> 
> static void stream_state_cb(pa_stream *stream, void *userdata);
>@@ -336,8 +338,14 @@ static void context_state_cb(pa_context *c, void *userdata) {
>             }
> 
>             requested_latency = pa_sink_get_requested_latency_within_thread(u->sink);
>+            /* FIXME: We should just let the server decide at this point. But
>+             *        we have to implement rewind support first or the very
>+             *        high latency will be too noticable. For now we have a
>+             *        hard coded default that gives a sane trade off. */
>             if (requested_latency == (pa_usec_t) -1)
>-                requested_latency = u->sink->thread_info.max_latency;
>+                requested_latency = PA_CLAMP(DEFAULT_LATENCY_USEC,
>+                                             u->sink->thread_info.min_latency,
>+                                             u->sink->thread_info.max_latency);
> 
>             reset_bufferattr(&bufferattr);
>             bufferattr.tlength = pa_usec_to_bytes(requested_latency, &u->sink->sample_spec);
>@@ -436,8 +444,14 @@ static void sink_update_requested_latency_cb(pa_sink *s) {
>     pa_assert_se(u = s->userdata);
> 
>     block_usec = pa_sink_get_requested_latency_within_thread(s);
>+    /* FIXME: We should just let the server decide at this point. But
>+     *        we have to implement rewind support first or the very
>+     *        high latency will be too noticable. For now we have a
>+     *        hard coded default that gives a sane trade off. */
>     if (block_usec == (pa_usec_t) -1)
>-        block_usec = s->thread_info.max_latency;
>+        block_usec = PA_CLAMP(DEFAULT_LATENCY_USEC,
>+                              s->thread_info.min_latency,
>+                              s->thread_info.max_latency);
> 
>     nbytes = pa_usec_to_bytes(block_usec, &s->sample_spec);
>     pa_sink_set_max_request_within_thread(s, nbytes);
>@@ -664,7 +678,6 @@ int pa__init(pa_module *m) {
>     u->sink->userdata = u;
>     u->sink->parent.process_msg = sink_process_msg_cb;
>     u->sink->update_requested_latency = sink_update_requested_latency_cb;
>-    pa_sink_set_latency_range(u->sink, 0, MAX_LATENCY_USEC);
>     pa_sink_set_get_volume_callback(u->sink, sink_get_volume_cb);
>     pa_sink_set_set_volume_callback(u->sink, sink_set_volume_cb);
>     pa_sink_set_get_mute_callback(u->sink, sink_get_mute_cb);
>-- 
>2.4.3
>

Actions: View | Splinter Review

Attachments on bug 91370: 117188 | 117189 | 117190

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.