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>
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.
When line out path is active, we want to mute speakers for obvious
reasons, and headphones to avoid volume spikes.
Reported-by: TienFu Chen <tienfu.chen@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
pa_source_state_t can have value PA_SOURCE_INVALID_STATE, not
PA_SINK_INVALID_STATE. It happens to be the same here, but it can break
sometimes.
Issue detected by PVS Studio.
I noticed that when resuming the tunnel sink, there was a small amount
of previously played audio before the new audio started to play.
Normally that probably wouldn't be noticeable, because there would be
a few seconds of silence played before suspending the sink due to
inactivity, so the unwanted old audio would be just silence, but in my
configuration sinks are suspended immediately when there's nothing
playing to them, so the glitch becomes audible.
The bluetooth card is created when the first profile becomes
available, which means that the card may have profiles that are not
available when the card is initialized. If module-card-restore tries
to restore such profile, that will fail, and the card will be
initialized with the "off" profile active.
This patch modifies module-card-restore so that if follows the profile
availability status, and when the saved profile becomes available, it
is activated. Additionally, module-card-restore is modified so that it
doesn't even try to restore unavailable profiles, when the necessary
information is available. In practice there are two existing places
where the profile is restored, and only one of those contexts has the
necessary information available. Unfortunately, it's the more
important context (card creation) where the information is not
available. This means that module-card-restore will set the initial
profile of a new card even if the profile is unavailable, and this
will cause an ugly warning in the log, even though there's nothing
abnormal happening.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=87081
In case a transport is currently disconnected and transitions to
idle, that should not count as a "remote hang up" event.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
