Adding AGC broke this test, so we hard-disable the volume code in test
mode. This is probably okay for now, since at least with analog AGC, the
source volume changes and the data we get is going to be with AGC
applied, but digital gain won't be encapsulated here.
Long term, we might need to figure out how to deal with this properly.
We encountered an alsa plugin a while ago (not sure if the source
can be shared) which had mixer controls, but no descriptors to
poll for changes.
Quit early to avoid latter assertion failures.
BugLink: https://bugs.launchpad.net/bugs/1092377
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The combination "Front Headphone" + "Headset Mic Phantom"
was found on one the machines we enable. Without this patch,
the headset mic appeared plugged in when nothing was plugged
into the jack.
BugLink: https://bugs.launchpad.net/bugs/1513384
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
In rtp.c:
if (sscanf(t+9, "%i %64c", &_payload, c) == 2)
the string c seems to be non-null terminated. It is later used as
following:
c[strcspn(c, "\n")] = 0;
The same piece of code is responsible for the inability of pulseaudio
on OpenWRT to handle RTP stream at the rate 48000 from another
machine:
[pulseaudio] sdp.c: Failed to parse SDP data: missing data.
It turns out that uClibc does not agree with glibc about "%64c", see
http://git.uclibc.org/uClibc/tree/docs/Glibc_vs_uClibc_Differences.txt
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=92568
We currently only support one and two channels for volumes, and
bail out otherwise. This makes Xonar users unhappy because they
have a volume with eight channels, and bailing out means they
don't have a path/port at all.
This way they will at least have a port, which will in turn make
the gnome/unity UI behave better.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=84983
BugLink: https://bugzilla.gnome.org/show_bug.cgi?id=745017
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
In case the same jack causes one port to become available and another
one unavailable, the available should be reported first.
This is to avoid unnecessary changes: e g, consider a 'Headphone Jack'
making 'Headphone' available and 'Speaker' unavailable. In case the
unavailable change triggers first, and there is also a currently available
third port (e g 'Digital out'), the routing system might choose to route
to this port because neither of the 'Speaker' and 'Headphone' ports are
available.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
I'm not sure how much they are needed nowadays with the latest
changes to the subset elimination (I found this while
researching a bug on an older PA version), but I guess they could
be added for consistency at least.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Originally pointed out by Georg Chini.
Calculating buffer = buffer + (send_counter - recv_counter)
in one branch and buffer = 2 * buffer - (recv_counter - send_counter)
looks very obviously wrong. In other words, before the patch, the
contribution from the previous lines was double-counted.
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
