On 2014-11-05 00:26, Peter Meerwald wrote:
From: Peter Meerwald <p.meerw...@bct-electronic.com>
... in order to increase the chance that SHMRELEASE will be combined
with some other message; SHMRELEASE gets into the send queue, but
the mainloop is not notified about it
...the idea being that shmrelease is not crucial to get any time soon,
it's just about reclaiming memory anyway. But is there a risk that they
never get sent? E g, if the stream gets corked, stopped, runs out of
data, or something, and now we just have all of these waiting in the
send queue, but there is no reason to send anything else, so they'll be
waiting there indefinitely?
Signed-off-by: Peter Meerwald <pme...@pmeerw.net>
---
src/pulsecore/pstream.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/pulsecore/pstream.c b/src/pulsecore/pstream.c
index e1b84c6..88bf5d4 100644
--- a/src/pulsecore/pstream.c
+++ b/src/pulsecore/pstream.c
@@ -459,7 +459,11 @@ void pa_pstream_send_release(pa_pstream *p, uint32_t
block_id) {
#endif
pa_queue_push(p->send_queue, item);
- p->mainloop->defer_enable(p->defer_event, 1);
+ /* Don't call defer_enable() to increase the chance that
"Don't call defer_enable() here. This increases the chance that"
+ * the SHMRELEASE item can be combined with some other
+ * item and sent together in one mini buffer.
+ * p->mainloop->defer_enable(p->defer_event, 1);
+ */
}
/* might be called from thread context */
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
