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
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.
Commit fa092af59c removed an argument to pa_rtpoll_run, but
forgot to remove that argument for all callers to pa_rtpoll_run.
This commit removes the remaining ones.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
I think this makes the code a bit nicer to read and write. This also
reduces the chances of off-by-one errors when checking the bounds of
channel count values.
Changes since v1:
Use max value of jack_port_get_latency_range to calculate the latency
and squash compiler warnings cased by using jack_port_get_total_latency
Modifying latency only works inside a callback, and for hardware the
latency is generally fixed on jack, so just take the max value.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Just picking up a crash report from Ubuntu, here's the result.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 934c52c79bb6faed56a64d6e15f9b285f687afee Mon Sep 17 00:00:00 2001
From: David Henningsson <david.henningsson@canonical.com>
Date: Mon, 28 Mar 2011 14:30:44 +0200
Subject: [PATCH] module-jack-sink/source: protect against null return in jack_get_ports
According to jack_get_ports documentation, it seems like returning NULL
is valid, and that it should be freed using jack_free.
Reported-by: Grayson Peddie
BugLink: http://bugs.launchpad.net/bugs/733424
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
