This fixes a crash. sink_input_pop_cb() drains the message queue that receives
memchunks from the combine sink thread to avoid requesting more audio too soon.
The same message queue received also SET_REQUESTED_LATENCY messages, which
generate rewind requests. Rewind requests shouldn't be issued in the pop()
callback, doing so results in an assertion error. Therefore, it was not safe to
drain the message queue in the pop() callback, but usually the queue is empty,
so this bug was not immediately detected.
This patch splits the message queue into two queues: audio_inq and control_inq.
audio_inq receives only messages containing memchunks, and control_inq receives
only the SET_REQUESTED_LATENCY messages. The pop() callback only drains the
audio queue, which avoids the rewind requests in the pop() callback.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90489
When we the underlying sink/source goes away, there is an intermediate
state where the asyncmsgqs that we were using for the sink-input and
source-output go away. This is usually okay if the sink-input and
source-output are moved to another device, but can be problematic if we
don't support moving (which is the case when the filter is autoloaded).
This becomes a problem because of the following chain of events:
* The underlying sink goes away
* Moving the filter sink-input fails (because it is autloaded)
* At this point the sink-input has no underlying sink, and thus
no underlying asyncmsgq
* This also applies to all sink-inputs connected to the echo-cancel
module
* The sink-input is killed, triggering a module unload
* On unlink, module-rescue-streams tries to move sink-inputs to
another sink, starting with a START_MOVE message
* There is no asyncmsgq for the message, so we crash
* We can't just perform a NULL check for the asyncmsgq, since there
are state changes we need to effect during the move
To fix this, we pretend to allow the move to the new sink, and then
unlink ourselves *after* the move is complete. This ensures that we
never find ourselves in a position where we need the underlying
sink/asyncmsgq to be present when it is not.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90416
Fixes a compiler warning:
../../src/modules/udev-util.c: In function 'pa_udev_get_info':
../../src/modules/udev-util.c:228:443: warning: 'bus' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (!pa_streq(bus, "firewire") && (v = udev_device_get_property_value(card, "ID_MODEL_FROM_DATABASE")) && *v)
This makes the GUIs (e g gnome/unity-control-center) look more consistent
with other inputs/outputs that also have ports.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This works around bug 80850: a mapping can only have one channel map,
and in case of a 6-out 10-in device, the mapping will be adjusted to
have both 10 and 6 channels, which does not work.
Reported-by: Benjamin Tegge <benjaminosm@googlemail.com>
Suggested-by: Raymond Yau <superquad.vortex2@gmail.com>
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=80850
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
For recently supported FireWire sound devices, udev's database assign
the name of IEEE 1394 Phy/Link chipset to ID_XXX_FROM_DATABASE. This is
not friently names to users.
This commit applies a workaround to skip ID_XXX_FROM_DATABASE for any
FireWire devices.
[Fixed up by David Henningsson <david.henningsson@canonical.com>]
Reported-by: Andras Muranyi <muranyia@gmail.com>
Reference: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1381475
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
CoreAudio routines that return an error status do so with the
OSStatus type, which is not a UInt32: typical OS X errors are
negative numbers.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Add a user defined parameter lfe-crossover-freq for the lfe-filter,
to pass this parameter to the lfe-filter, we need to change the
pa_resampler_new() API as well.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Flushing the asyncmsgq can cause arbitrarily callbacks to run, potentially
causing recursion into pa_thread_mq_done again. Because of this; rtpoll which
is cleared in the second iteration is tried to free once again by the first
iteration leading to PA crash.
pa_tagstruct_new() is called either with no data, i.e. (NULL, 0)
to create a dynamic tagstruct or with a pointer to fixed data
introduce a new function pa_tagstruct_new_fixed() for the latter case
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
This change doesn't affect behaviour, because accessing boolean fields
in the new data was safe even after the done() call, but it was still
bad style.
Message id 0 is PA_SOURCE_OUTPUT_MESSAGE_GET_LATENCY. So, every time PulseAudio
sent PA_SOURCE_OUTPUT_MESSAGE_GET_LATENCY message to the loopback source output,
it actually hit the SOURCE_OUTPUT_MESSAGE_LATENCY_SNAPSHOT handler instead. As a
result, the SOURCE_OUTPUT_MESSAGE_LATENCY_SNAPSHOT handler was called when not
intended, the default PA_SOURCE_OUTPUT_MESSAGE_GET_LATENCY handler was not called
at all, and the latency was thus evaluated incorrectly.
Reported-by: Georg Chini <georg@chini.tk>
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
...because we will later try with plug:* which will probably succeed,
so this is not an error.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This fixes a crash that occurred when trying to access non-existent
port data. Doing this:
pa_alsa_port_data *data = PA_DEVICE_PORT_DATA(port);
is not a good idea when using UCM, because in the UCM mode ports don't
have any data, so the data pointer points to some random memory.
During my work on module-loopback I found a bug that sometimes crashes pulse when
module-loopback is loaded due to pushing a zero-length block into the memblockq.
As there is a one-line fix I thought you might want it for 6.0.
ALSA mutes speaker when Line Out is plugged in by default, so
we should follow that convention.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
