When starting via a console login, PA will likely not have a session DBus
to play with. As there is no X11 environment, libdbus will be unable
to launch a session DBus for us and thus the module will fail to load
which in turn prevents PA from loading.
If the user subsequently logs into X11 this it will still not be possible
to load the module as the server will be ignorant of the X11 and DBus
environment variables so a longer term solution for handling this should
be found.
Some of the license wording was less than clear. Try to clarify the
different GPL 'downgrade' scenarios but also be generic to ensure that
those packagers where GPL is a problem check thoroughly before they ship.
Inspired by comments from Brian Cameron @ Oracle via fdo#41822
I'd rather not have to do this, as I don't really see the point in
duplicating what is done in pkgconfig, but this is likely the
easiest way to avoid nasty hacks.
module-stream-restore and modile-filter-apply can get into an infinite
loop if m-s-r is called before m-f-a (m-s-r rescues a stream and
attaches it to a sink/source, which then triggers m-f-a to move it back
to the filter sink/source, and so on). The purpose of the m-f-a hooks is
to beat m-s-r, so moving them to be run first.
This problem was found when tracing down a crash coming from the
esound protocol, which does not set a channel map.
BugLink: http://bugs.launchpad.net/bugs/864071
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
N.B.: As Colin notes, this is because commit 117c7145 was incomplete
("format: Fix channel map handling")
If module-jackdbus-detect failed in the later part of initialization,
the ma variable was freed twice.
BugLink: http://bugs.launchpad.net/bugs/867444
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Instead of relying on the snd_mixer_* functions failing, we check for
POLLERR and POLLNVAL first. After this, any errors in handling the mixer
events are deemed fatal (that is we cause the ALSA source/sink thread to
terminate).
The case where POLLERR is set but POLLNVAL is not does not actually
occur, but we're making this a soft failure (stop polling the mixer, but
don't kill the I/O thread). If other conditions where POLLERR occurs
turn up, we need to handle them explicitly.
Thanks to Linus Torvalds for helping get this right.
Loading between a sink and its monitor causes a deadlock (while sending
messages for latency snapshots). It isn't a case that has any real
conceivable use, so let's just disallow it.
This improves the error handling in the mixer rtpoll callback. It avoids
a crash if an error occurs (the rtpoll_item is freed but still
referenced), and specifically makes sure we don't continue trying to
poll the device if the card is disconnected.
This makes set_formats() put PCM formats lower down the list than
compressed formats since we negotiate by picking the first format in
this list that is also in the client-provided list of possible formats
during sink input creation.
This will be incorrect if we ever decide to do encoding in PA (for
things like AC3/DTS encoding for multichannel output over S/PDIF).
This patch was already added earlier with commit ID 2f86ba4f, but the
changes got reverted by commit 3adc43b ("win32: Make once-test work").
However, this still doesn't work on OSX as here, pthread is in general
available, but the barrier APIs aren't.
For both the headers and the library we should provide clean, three part
strings as this has been what we've previously done in the past
and some external systems apparently rely on this format. While it's not
something we've officially commented on before, there is no real advantage
to us to change it so let's not try to tidy things up too much
considering some third party apps (e.g. Skype) seem to dislike a two
part version string.
pa_{sink,source}_volume_change_apply were being called by the ALSA I/O
thread on every iteration, causing a pa_rtclock_now() call, which can
sometimes be heavy. We avoid this call by making sure there actually are
changes to apply before proceeding into the function.
While we're at it, also dropping a redundant check on s->write_volume.
Once in a million or so, this typo causes a crash when two threads
simultaneously try to call "pa_asynqmsgq_write_poll".
BugLink: http://bugs.launchpad.net/bugs/853560
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
If module-dbus-protocol fails to start, pa__done is still called,
which falsified the assumption that u->connections was always set.
BugLink: http://bugs.launchpad.net/bugs/855729
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This makes sure that when we're traversing the device chain for sources
and sinks with shared volume, we handle the case that a sink-input or
source-output of one of these might be unlinked (while unloading a
module, for example).
module-dbus-protocol gets the default sink, which sets the default sink
if not already set. This is turn makes module-default-device-restore do
nothing.
To solve the problem, make sure module-default-device-restore is loaded
before module-dbus-protocol and not the other way around.
BugLink: http://bugs.launchpad.net/bugs/843780
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Sometimes the ALSA mixer can be modified during a point at shutdown
which causes a race condition trying to update the volume of an
unlinked sink.
Includes typo fix by our Chief Typo Spotter, Colin, and a clarifying
comment by me.
BugLink: http://bugs.launchpad.net/bugs/841968
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Uses the shared volume infrastructure by default with an option to
fallback on the old pretend-volume-sharing-that-kind-of-works if someone
wants it that way.
Users who keep left != right (or any sort of unbalanced channel volumes)
will likely want to disable shared volumes since it will cause their
master sink/source volume to be balanced.
This really isn't a very pleasant scenario since users would need to
manually set up echo cancellation in their config for this (until we
have a way to store module configuration). That said, the majority case
benefits from the volume sharing, so let's not wait for the
configuration infrastructure to be ready to use this.
Uses the shared volume infrastructure by default with an option to
fallback on the old pretend-volume-sharing-that-kind-of-works if someone
wants it that way.
This handles the case where a virtual sink/source and it's master have
different channel counts. The solution is not ideal because if the
former has fewer channels and the master has channel volumes that are
not all at the same level, it will lose this information and have all
channels at the same level.
This is not just a theoretical problem, since module-echo-cancel
prefers a mono virtual source/sink and will usually be sitting on top of
a stereo ALSA source/sink.
That said, I don't really see a good solution to this problem, so the
idea is to make volume sharing optional (on by default) in
module-echo-cancel, so that the few people who care can then disable it
if they so desire.
This just covers Lennart's concern over the terminology used.
The majority of this change is simply the following command:
grep -rli sync[-_]volume . | xargs sed -i 's/sync_volume/deferred_volume/g;s/PA_SINK_SYNC_VOLUME/PA_SINK_DEFERRED_VOLUME/g;s/PA_SOURCE_SYNC_VOLUME/PA_SOURCE_DEFERRED_VOLUME/g;s/sync-volume/deferred-volume/g'
Some minor tweaks were added on top to tidy up formatting and
a couple of phrases were clarified too.
When dealing with proplists passed as modargs, we need the unescaped form
in order to properly deal with quotes (ticks + double quotes). As the previous
code always called pa_unescape() before adding it into the modarg hashmap, this
was impossible.
This modification simply stores two proplists. If the unescaped value
is different from the raw value, we also keep the raw form.
When parsing proplist arguments, we use this raw form and do the unescaping
ourselves when processing it.
This changes the current behaviour which required you to double escape
proplists arguments. This double escape mechanism did allow you to mix
and match what types of quotes you used to delimit the individial
proplist values, but it made the actual data much harder to pass in.
This approach has the drawback that you cannot mix and match the quotes
you use, but this is a very minor issue and IMO pales in comparison to
the general clarity gained.
See the discussion on the mailing list for more background:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011220.html
The Kinect shows up as a UAC device after the firmware has been loaded,
but in order to be detected by pulseaudio a 4-channels input only
mapping is needed. Provide a new profile for that and set it with a udev
rule.
fdo#39664
