Previously the UCM code created one jack object per device name (which
is not the same thing as creating one jack object per device, because
the UCM device namespace is scoped on per-verb basis, so devices in
different verbs may have the same name). I think it's conceptually
cleaner to create one jack object per alsa kcontrol. I plan to do
similar refactoring on the traditional mixer code later.
Previously module-alsa-card assigned to pa_alsa_jack.plugged_in
directly, and then did the port availability updating manually. The
idea of pa_alsa_jack_set_plugged_in() is to move the availability
updating to the mixer infrastructure, where it really belongs.
Similarly, pa_alsa_jack.has_control was previously modified directly
from several places. The has_control field affects the port
availability, and pa_alsa_jack_set_has_control() takes care of
updating the availability.
For now, pa_alsa_jack_set_plugged_in() and
pa_alsa_jack_set_has_control() only update the port availability
when using UCM. My plan is to adapt the traditional mixer code later.
"Front Line Out" was found in the wild on one of the machines we enable.
I figured I could just as well add "Rear Line Out" too, because that's
just as likely to show up.
As a reminder, "Front Line Out" means "a line out jack physically located
on the front side", where as "Line Out Front" means "a line out jack
playing back front left and front right channels in a channel map".
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
These mapping names are used in sb-omni-surround-5.1.conf, which needs
to use separate mappings for input and output, since they are
associated with different alsa devices.
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>
