Let's assume that there are two output ports, and they are on
different profiles:
* Integrated speakers (priority: 10000, available)
* HDMI (priority: 5900, not available)
Then the user plugs in an HDMI monitor with speakers. Since the HDMI
priority is lower than the speaker priority, we don't route to HDMI by
default. However, the user manually switches the profile to use the
HDMI output.
Then the user plugs out the monitor, so we switch back to speakers.
When the monitor is plugged back in, the user needs to manually switch
the audio output again. That should be improved: if the user preferred
to the HDMI output over the speakers, we should remember that and
automatically switch to HDMI whenever it becomes available.
The lack of automatic switching is even worse when the monitor goes to
a sleep mode after some period of inactivity. The monitor audio may
become unavailable, and PulseAudio can't distinguish that from the
case where the monitor is physically unplugged. Even worse, the
monitor may become unavailable for a short while when adjusting the
display parameters (for example, media center software may adjust the
display parameters to match the media that is being played back). In
these cases we clearly should switch automatically back to HDMI when
it becomes available again.
This patch fixes the problem by setting pa_card.preferred_input_port
and pa_card.preferred_output_port when the user changes the card
profile or a port, and switching to the preferred port when it becomes
available.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=93946
If you have headphones plugged in and plug in HDMI; you want sound
to stay on headphones.
If you have HDMI plugged in and you plug in headphones; you want sound
to switch to headphones.
Hence we need to take priority into account as well when determining
whether to switch to a new profile or not.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=93903
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This makes the routing slightly more aggressive:
* It will try to route to another profile, if such a profile
is preferred by the port.
* It will allow changing profiles on transitions both to
PA_AVAILABLE_YES and PA_AVAILABLE_NO
To accommodate there is also some refactoring.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
In case input or output names are filled in, we can use this to
get a better match in the profile_good_for_input/output functions
instead of guessing based on number of sources and channels.
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.
It is possible that the chosen active_port doesn't equal
new_data->active_port, using p->name is more accurate.
Please refer to sink_new_hook_callback()
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Now that we have a generic function in device-port.h, we can use
it instead of the custom one.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We now have a port->card pointer, we can use it instead of iterating
over cards to find the correct one.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
When setting attribute foo, or in this case the card profile, in my
opinion the thing passed to the set_foo() function should be of the
type of foo, not a string identifier that can be used to search for
the actual foo in set_foo().
This is mostly a question of taste, but there's at least some small
benefit from passing the actual object: often the profile object is
already available when calling pa_card_set_profile(), so passing the
card name would cause unnecessary searching when pa_card_set_profile()
needs to look up the profile from the hashmap.
This patch removes all occurrences of double and triple
newlines.
Command used for this:
find . -type d \( -name ffmpeg \) -prune -o \
-regex '\(.*\.[hc]\|.*\.cc\)' \
-a -not -name 'adrian-aec.*' -a -not \
-name reserve.c -a -not -name 'rtkit.*' \
-exec sed -i -e '/^$/{N;s/^\n$//}' {} \;
Two passes were needed to remove triple newlines.
The excluded files are mirrored files from external sources.
This patch replaces every occurrence of ')\n{' with ') {'.
Command used for this:
find . -type d \( -name ffmpeg \) -prune -o \
-regex '\(.*\.[hc]\|.*\.cc\)' \
-a -not -name core-util.c -a -not \
-name adrian-aec.c -a -not -name g711.c \
-exec sed -i -e '/)$/{N;s/)\n{$/) {/}' {} \;
The excluded files are mirrored files from external sources.
As an extra, I broke try_to_switch_profile() into smaller
functions, because the two levels of loops with continue
statements inside both were a bit hard to follow.
If a card is hot-plugged (which all cards will be when we load
this module before module-*-detect), make sure we don't start up
a sink with an unavailable port selected.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Generalize the availability flag in order to be used beyond the scope of
ports.
However, pa_port_availability_t is left unchanged to avoid modifying the
protocol and the client API. This should be replaced by pa_available_t
after a validation phase of this new generic enum type.
In practice there is always at least one profile, and I
don't think there will ever be cards without profiles.
Therefore, I added assertions to pa_card_new() stating that
the card new data must always contain at least one profile.
Now a lot of code can be simplified, because it's guaranteed
that the profiles hashmap and the active_profile field are
always non-NULL.
For switching profiles, we are a little more cautious, only switch
from an unavailable port to an available one. Profile switching is
mainly used for HDMI/DisplayPort, and this is to avoid switching from
analog to HDMI/DP when it becomes available.
See http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-March/012991.html
and replies for more information.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
While developing the new UI we had to ask ourselves the question of whether
"speakers" should be considered available when headphones are plugged in.
In most cases, they are not available and therefore we should list them
as such.
OTOH, we don't want unplugging the headphones to be considered an act of
wanting to use the speakers (the user might prefer HDMI), and there might
be line-outs that keeps the speakers from unmuting anyway. So, at this point,
I think the most reasonable would be to make the speakers have
PA_PORT_AVAILABLE_NO when headphones are plugged in and
PA_PORT_AVAILABLE_UNKNOWN when they are not. But we might want to revisit
this decision once we have the priority lists up and running.
The same reasoning applies for "Internal Mic", which should become unavailable
when any other mic is plugged in.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This module tries to switch to a port when availability changes to
"YES", and tries to switch away when availability changes to "NO".
Once there is a priority list infrastructure in place and ready,
this functionality might be redundant, but this will do as an
interim solution.
