From df92274787edc2d5cba32df3c9c191d8378f8325 Mon Sep 17 00:00:00 2001 From: Tanu Kaskinen Date: Fri, 28 Oct 2016 19:00:26 +0300 Subject: [PATCH 1/4] 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. --- src/pulse/thread-mainloop.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pulse/thread-mainloop.h b/src/pulse/thread-mainloop.h index 40278b4d7..e69298aa0 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; From b6777d7f090d4e765c93709e3a9ca178e82ba954 Mon Sep 17 00:00:00 2001 From: Tanu Kaskinen Date: Sat, 13 Aug 2016 01:12:31 +0300 Subject: [PATCH 2/4] 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. --- src/modules/module-pipe-sink.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/modules/module-pipe-sink.c b/src/modules/module-pipe-sink.c index da6502115..1c688d77c 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); From 2432270a73294676d43918beb99b7303040b274a Mon Sep 17 00:00:00 2001 From: Tanu Kaskinen Date: Tue, 4 Apr 2017 12:46:25 +0300 Subject: [PATCH 3/4] 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 --- src/pulsecore/protocol-native.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/pulsecore/protocol-native.c b/src/pulsecore/protocol-native.c index 13f4f6238..efe9bd244 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; From a604d9cbb3199c2a4c7e12e37def228a43553890 Mon Sep 17 00:00:00 2001 From: Tanu Kaskinen Date: Wed, 8 Jun 2016 21:18:52 +0300 Subject: [PATCH 4/4] 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. --- src/pulsecore/memblock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pulsecore/memblock.c b/src/pulsecore/memblock.c index dbad32a28..fb83dac57 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 */