[pulseaudio-commits] 4 commits - src/modules src/pulse src/pulsecore

[Tanu Kaskinen]

 src/modules/module-pipe-sink.c  |    9 ++++++---
 src/pulse/thread-mainloop.h     |    2 +-
 src/pulsecore/memblock.c        |    2 +-
 src/pulsecore/protocol-native.c |    5 +++++
 4 files changed, 13 insertions(+), 5 deletions(-)

New commits:
commit a604d9cbb3199c2a4c7e12e37def228a43553890
Author: Tanu Kaskinen <tanuk at iki.fi>
Date:   Wed Jun 8 21:18:52 2016 +0300

    memblock: multiple references should make blocks read-only
    
    The old code makes no sense to me. Why would multiple references mean
    that a previously read-only memblock is suddenly writable? I'm pretty
    sure that the original intention was to treat multi-referenced blocks
    as read-only. I don't have any examples where the old code would have
    caused bad behaviour, however.

diff --git a/src/pulsecore/memblock.c b/src/pulsecore/memblock.c
index dbad32a2..fb83dac5 100644
--- a/src/pulsecore/memblock.c
+++ b/src/pulsecore/memblock.c
@@ -497,7 +497,7 @@ bool pa_memblock_is_read_only(pa_memblock *b) {
     pa_assert(b);
     pa_assert(PA_REFCNT_VALUE(b) > 0);
 
-    return b->read_only && PA_REFCNT_VALUE(b) == 1;
+    return b->read_only || PA_REFCNT_VALUE(b) > 1;
 }
 
 /* No lock necessary */

commit 2432270a73294676d43918beb99b7303040b274a
Author: Tanu Kaskinen <tanuk at iki.fi>
Date:   Tue Apr 4 12:46:25 2017 +0300

    protocol-native: log who changes card profiles
    
    Some volume control applications, including gnome-control-center[1],
    Budgie Volume Control[2] and possibly something in xfce4 too[3],
    sometimes do unwanted card profile changes. This patch makes it possible
    to see from the log which application requested a profile change, which
    makes it easier to detect when an application misbehaves.
    
    [1] https://bugzilla.gnome.org/show_bug.cgi?id=762932
    [2] https://bugs.freedesktop.org/show_bug.cgi?id=93903#c41
    [3] https://bugs.freedesktop.org/show_bug.cgi?id=93903#c40

diff --git a/src/pulsecore/protocol-native.c b/src/pulsecore/protocol-native.c
index 13f4f623..efe9bd24 100644
--- a/src/pulsecore/protocol-native.c
+++ b/src/pulsecore/protocol-native.c
@@ -4721,6 +4721,11 @@ static void command_set_card_profile(pa_pdispatch *pd, uint32_t command, uint32_
 
     CHECK_VALIDITY(c->pstream, profile, tag, PA_ERR_NOENTITY);
 
+    pa_log_info("Application \"%s\" requests card profile change. card = %s, profile = %s",
+                pa_strnull(pa_proplist_gets(c->client->proplist, PA_PROP_APPLICATION_NAME)),
+                card->name,
+                profile->name);
+
     if ((ret = pa_card_set_profile(card, profile, true)) < 0) {
         pa_pstream_send_error(c->pstream, tag, -ret);
         return;

commit b6777d7f090d4e765c93709e3a9ca178e82ba954
Author: Tanu Kaskinen <tanuk at iki.fi>
Date:   Sat Aug 13 01:12:31 2016 +0300

    pipe-sink: set correct latency
    
    The old pa_sink_set_fixed_latency() call didn't take into account that
    other places use pa_frame_align() on the pa_pipe_buf() result, so the
    configured latency could be sometimes slightly too high.
    
    Adding a buffer_size variable in userdata makes it a bit easier to keep
    all places that deal with the buffer size in sync.

diff --git a/src/modules/module-pipe-sink.c b/src/modules/module-pipe-sink.c
index da650211..1c688d77 100644
--- a/src/modules/module-pipe-sink.c
+++ b/src/modules/module-pipe-sink.c
@@ -75,6 +75,7 @@ struct userdata {
 
     char *filename;
     int fd;
+    size_t buffer_size;
 
     pa_memchunk memchunk;
 
@@ -123,7 +124,7 @@ static int process_render(struct userdata *u) {
     pa_assert(u);
 
     if (u->memchunk.length <= 0)
-        pa_sink_render(u->sink, pa_frame_align(pa_pipe_buf(u->fd), &u->sink->sample_spec), &u->memchunk);
+        pa_sink_render(u->sink, u->buffer_size, &u->memchunk);
 
     pa_assert(u->memchunk.length > 0);
 
@@ -306,8 +307,10 @@ int pa__init(pa_module *m) {
 
     pa_sink_set_asyncmsgq(u->sink, u->thread_mq.inq);
     pa_sink_set_rtpoll(u->sink, u->rtpoll);
-    pa_sink_set_max_request(u->sink, pa_frame_align(pa_pipe_buf(u->fd), &u->sink->sample_spec));
-    pa_sink_set_fixed_latency(u->sink, pa_bytes_to_usec(pa_pipe_buf(u->fd), &u->sink->sample_spec));
+
+    u->buffer_size = pa_frame_align(pa_pipe_buf(u->fd), &u->sink->sample_spec);
+    pa_sink_set_max_request(u->sink, u->buffer_size);
+    pa_sink_set_fixed_latency(u->sink, pa_bytes_to_usec(u->buffer_size, &u->sink->sample_spec));
 
     u->rtpoll_item = pa_rtpoll_item_new(u->rtpoll, PA_RTPOLL_NEVER, 1);
     pollfd = pa_rtpoll_item_get_pollfd(u->rtpoll_item, NULL);

commit df92274787edc2d5cba32df3c9c191d8378f8325
Author: Tanu Kaskinen <tanuk at iki.fi>
Date:   Fri Oct 28 19:00:26 2016 +0300

    thread-mainloop: fix volatile use in example
    
    In the example, drain_result is a volatile pointer to an int, not
    a regular pointer to a volatile int.

diff --git a/src/pulse/thread-mainloop.h b/src/pulse/thread-mainloop.h
index 40278b4d..e69298aa 100644
--- a/src/pulse/thread-mainloop.h
+++ b/src/pulse/thread-mainloop.h
@@ -164,7 +164,7 @@ PA_C_DECL_BEGIN
  * access this data safely, we must extend our example a bit:
  *
  * \code
- * static volatile int *drain_result = NULL;
+ * static int * volatile drain_result = NULL;
  *
  * static void my_drain_callback(pa_stream*s, int success, void *userdata) {
  *     pa_threaded_mainloop *m;