When fallback mapping is selected all subsequent profile sets containing
selected mapping are ignored. When there are only e.g. fallback input mappings
available, admitted profile set will only contain one profile with selected
first input fallback mapping and no outputs, and rest of profiles will only
contain outputs and no inputs. When there are only fallback input and output
mappings, there will be no profiles admitted at all.
Fix this by making sure that selected first fallback input or output mapping
is actually allowed to exist in all probed profile sets.
Note while this change allows selected fallback mappings to be found in duplex
configuraitons, probing fallbacks still can fail if there is more than one input
fallback and first one (selected) does not work in duplex configurations.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/539>
Since commit cb91d7a1 the watermark is increased when there is nothing to rewind.
This is also done in the case when there was actually no rewind requested at all,
so the watermark is increased needlessly.
This patch fixes the issue by skipping the rewind if none is requested.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/530>
Intel TGL HDMI/DP codec provides 9 pins (Linux kernel, 9a11ba7388f16:
ALSA: hda: hdmi - add Tigerlake support), and with the DP MST enabled,
the linux kernel will build 11 output devices (3, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16), and the alsa-lib will map 11 PCM devices from HDMI:0
to HDMI:10, but current pulseaudio only supports 8 HDMI/DP devices,
if users plug the HDMI/DP monitor to the last 3 ports, the users will
not see the output device from pulseaudio or gnome.
We have experienced this issue on a dell TGL machine with a dock, we
plugged 2 HDMP/DP monitors on the dock, but we could only see 1
HDMI/DP output device from pulseaudio or gnome, through investigation,
we found one monitor is plugged in the 2nd port from last.
Here we add 3 HDMI/DP output devices.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/495>
Volume scaling in dB mode is broken if max dB is negative.
I have a Nobsound USB amplifier (1908:2220) that reports a dB range
of -127.07 dB to -128 dB in Alsa.
While this is likely a driver/device bug, in my naive imagination
userspace wouldn't bother too much with the absolute values and just set
out_dB(percent) = min_dB + (max_dB - min_dB) * percent
However, this is not what PulseAudio is doing, instead max_dB is used
as base_volume with which the desired software volume is multiplied
while min_dB does not seem to be taken into account.
The result is that with this device only a tiny portion of the volume
slider is usable.
Setting it to 97% already reaches min_dB which effectively turns any
(software) audio knob to an on/off switch.
To work around this, simply set the has_dB flag to false if max_dB is
negative.
This falls back to using raw Alsa values (ranging from 0 - 255), now
the settings in pavucontrol perfectly mirror those in alsamixer.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/447>
After applying the commit 0d50e787 ("alsa-card: improve the profile
availability logic"), we met an new issue. when system selects the
initial profile, the profile off is selected instead of a profile with
a valid output device on it. That is the issue we met:
Profiles:
HiFi: Default (sinks: 2, sources: 2, priority: 8000, available: no)
off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
Active Profile: off
Ports:
[Out] Headphones: Headphones (priority: 300, latency offset: 0 usec, not available)
Part of profile(s): HiFi
[Out] Speaker: Speaker (priority: 100, latency offset: 0 usec)
Part of profile(s): HiFi
...
I know the commit 0d50e787 really fixed something, but we still need
to fix the new issue, to do so, this patch introduces a priority bonus
for alsa profiles and separate the alsa profiles to 3 groups:
group a (will be granted priority bonus dynamically):
a profile has only output ports and at least one port is not unavailable
a profile has only input ports and at least one port is not unavailable
a profile has both input and output ports, and at least one output and
one input ports are not unavailable
group b (will be marked unavailable)
a profile has only output ports and all ports are unavailable
a profile has only input ports and all ports are unavailable
a profile has both output and input ports, and all ports are unavailable
group c
the rest profiles, their priority and availability is not changed.
With this change, the profile HiFi will become avaialbe:yes, and will
not be granted priority bonus if no input port is plugged.
The priority bonus provides a higher priority base to profiles, this
guarantees this patch doesn't break the fix of 0d50e787.
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/927
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/355>
This is seen at least on HP EliteDesk 800 DM and HP EliteDesk 800 SFF.
This is used by the analog-output-headphones-2 path, but all other paths
on the same sink need to handle the element too. The existing
configuration is inconsistent between files regarding whether headphone
outputs should be muted or not when not using them. I chose to be
consistent within files, which means that Headphone,1 handling is
inconsistent between files in the same way that the existing Headphone
and Headphone2 handling is. (My opinion is that unused paths should be
always muted, but I didn't want to do that policy change in this patch.)
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/272>
Previously both paths had description "Headphones", which I assume can
cause confusion with users who see two ports with identical names. I
don't have this kind of hardware myself nor have I heard complaints from
users, this is just something I noticed while reading the configuration
files.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/272>
We have at least one USB hardware which supports the 8
channels in one mixer element:
https://github.com/alsa-project/alsa-ucm-conf/pull/25
POSITION_MASK_CHANNELS define was added for the future extensions.
The override_map variable was changed from bool to mask (unsigned int).
The channel map override settings is handled for channels up to eight now.
Also added missing override-map.3 .. override-map.8 to the configuration
parser array.
The driver channel position was added to the override mask arguments
(syntax is driver:pulseaudio like left:all-left). If ommited, the ALSA's
channel positions are guessed by index.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/292
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/389>
Use safe values for the min_dB and max_dB fields when the position mask
is unset to avoid breakage for the upper levels.
If the range is incorrect, the volume range shown in pavucontrol shows
strange values.
(Thanks to Wim Taymans for the idea.)
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/389>
The old behaviour was such that if none of the normal mappings worked,
we would probe ALL fallbacks. I don't think that makes sense, and it
caused concrete issues: let's say we have a regular stereo mic device,
but there's no "front" PCM defined for it. In this situation we would
probe the stereo-fallback mapping (which uses "hw" instead of "front"),
and it would work, but then we'd also probe the "multichannel-input"
mapping, which would also work, so we end up with two mappings that
don't have any difference in behaviour.
I think it's better to simply pick the first working fallback and ignore
the rest.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/901
(issue is marked as confidential due to unreleased hardware)
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/304>
Allow adding module arguments using udev PULSE_MODARGS environment variable and
fail module loading if there is a problem with PULSE_MODARGS
This helps setting e.g. 'tsched=0' for specific devices without a need to create
full load module entry in default.pa.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/436>
With the Auto-Mute enabled, if the headphone jack is plugged, the
alsa hda driver will mute the speaker and set pinctl of the speaker
to Hi-Z state, after this happens, even the pulseaudio unmute the
speaker, the speaker still couldn't output sound because the pinctl
is in Hi-Z state.
We found this issue on a Dell machine which has multi-function audio
jack, after the headphone is plugged in, the speaker's availability is
still unknown, users could select speaker from gnome-sound-setting,
but even the speaker is selected to be the active device, it couldn't
output sound.
The Auto-Mute is not useful if the pulseaudio is running since pa
could mute/unmute devices according to active port change, the ucm
for sof+hda already disabled the Auto-Mute, let us disable it for
hda audio if the machine has the internal speaker.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/433>
Since there is now support for specifying the index of an Element, add the
same config as is used for the output-mono variant, as they behave the same:
One volume control with no support for adjustments to the left and right
channels.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/274>
The HP Thunderbolt Dock [1] has two separate USB cards, a headset jack
and an optional module which is a speakerphone.
This patch adds new description for them, and mark the intended-roles as
phone for the speakerphone module.
[1] https://store.hp.com/us/en/pdp/hp-thunderbolt-dock-120w-g2-with-audio
We already supported the CLFE element, which should be semantically
equivalent, so I just copied all the CLFE element definitions.
The Center/LFE element is seen on Creative X-Fi with 20K1 chipset cards.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/978
modules/alsa/alsa-sink.c: In function ‘pa_alsa_sink_new’:
modules/alsa/alsa-sink.c:2603:15: warning: declaration of ‘state’ shadows a previous local [-Wshadow]
void *state;
^~~~~
modules/alsa/alsa-sink.c:2270:11: note: shadowed declaration is here
void *state = NULL;
^~~~~
CC modules/alsa/module_alsa_sink_la-module-alsa-sink.lo
modules/alsa/alsa-source.c: In function ‘pa_alsa_source_new’:
modules/alsa/alsa-source.c:2289:15: warning: declaration of ‘state’ shadows a previous local [-Wshadow]
void *state;
^~~~~
modules/alsa/alsa-source.c:1975:11: note: shadowed declaration is here
void *state = NULL;
^~~~~
modules/alsa/module-alsa-card.c: In function ‘prune_singleton_availability_groups’:
modules/alsa/module-alsa-card.c:691:71: warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith]
pa_hashmap_put(group_counts, p->availability_group, count + 1);
^
HDMI jacks are configured like this:
[Jack HDMI/DP]
append-pcm-to-name = yes
The pa_alsa_jack.name field is then "HDMI/DP" and pa_alsa_jack.alsa_name
is set to "HDMI/DP,pcm=3 Jack" or similar. If we compare the name fields
of HDMI paths, they appear to use the same jack element even though they
are different in reality, so all HDMI ports got incorrectly assigned to
the same availability group.
Previously they were set once per mapping, which caused the numbering to
restart from 1 for every mapping, so ports were incorrectly assigned to
the same group.
Almost all reports from users, I have seen in last years, were not valid.
The report is also printed when the system scheduler does not wake
the pulseaudio thread in the right time. Users are not able to distinguish
between slow machine and the real problem.
Move the log level from 'error' to 'debug' for those messages.
The right fix should be to measure the time between the call invocation and
return to determine (and skip) the scheduling problems, but it is another
extra code just to debug things.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Although the hdmi-output is in well_known_descriptions[] table,
the hdmi device names are indexed (hdmi-output-0), thus there
is no match to assign the proper type automatically.
This patch puts the correct hdmi type to all relevant hdmi
configuration files.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
We have a requirement to "hide" some hardware drivers, because
other (main) UCM configuration will refer them.
This patch use special error codes to notify the upper layers
to skip the module loading.
BugLink: https://github.com/alsa-project/alsa-ucm-conf/issues/30
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
There were three bugs:
1) j->state_plugged was set to PA_AVAILABLE_UNKNOWN too early. It must
be set only after we have found that the jack is shared by two ports.
The result of setting it too early was that no jack ever could have
the PA_AVAILABLE_YES status.
2) The inner jack loop iterated through p->jacks instead of p2->jacks,
so the code didn't compare jacks between two ports at all. As a result
all ports were put in the same availability group.
3) The inner jack loop checked j->state_plugged instead of
j2->state_plugged. The result was that the speaker port, which uses the
Headphone jack to toggle between unknown and unavailable, was put in the
same group with the headphone port.
If the profile is generated from UCM, the priority won't be set so it
stays as 0.
Assume a card has two available profiles, when the selected one becomes
unavailable, module-switch-on-port-available's find_best_profile()
should pick the next available one. However, since the priority is 0,
the "off" profile was chosen instead of the available one.
So let's set the priority to 1 to make profile that is available has
higher priority than "off" profile.
