This is intended to make the current and upcoming code a bit clearer, as
we won't need to constantly check for the existence of these idxsets
before using or operating on them.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/596>
It may be possible that the ALSA control element appears
again. Allow this combination by checking, if the pulseaudio
mixer element already exists. Do not create the duplicate
mixer element in this case.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/729>
PulseAudio v5.99 or later hits assertion at alsa-lib mixer API due to
wrong handling of removal event for mixer element.
pulseaudio: mixer.c:149: hctl_elem_event_handler: Assertion `bag_empty(bag)' failed.
The removal event is defined as '~0U', thus it's not distinguished from
the other type of event just by bitwise operator.
At the removal event, class implementator for mixer API should detach
mixer element from hcontrol element in callback handler since alsa-lib
has assertion to check the list of mixer elements for a hcontrol element
is empty or not after calling all of handlers. In detail, please refer to
MR to alsa-lib:
* https://github.com/alsa-project/alsa-lib/pull/244
This commit fixes the above two issues. The issue can be regenerated by
`samples/ctl` Python 3 script of alsa-gobject.
* https://github.com/alsa-project/alsa-gobject/
It adds some user-defined elements into sound card 0. When terminated by
SIGINT signal, it removes the elements. Then PulseAudio dies due to the
assertion.
Fixes: 1fd8848e64 ("alsa-util: Add functions for accessing mixer elements through mixer class")
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/728>
If UCM defines the private alsa-lib configuration, the ELD controls
are expected to use this device configuration too.
With this change:
I: [pulseaudio] alsa-util.c: Successfully attached to mixer '_ucm0009.hw:Loopback'
Without:
I: [pulseaudio] alsa-util.c: Successfully attached to mixer '_ucm0009.hw:Loopback'
I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:4'
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/673>
The hw: device can be addressed using the card index (hw:0)
or the card identifier (ASCII string - hw:Loopback). Both
mixers are equal.
The previous code was fine for the mixers without the UCM
private prefixes (_ucmXXXX). Make code more robust, create
two aliased mixer structures in the mixers array.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/673>
Even though the file name is currently behringer-umc22.conf, the USB ID
actually belongs to Texas Instruments PCM2902, which is a generic chip
used in multiple products. Some products have true mono input unlike
Behringer UMC22, which has two mono inputs combined into one stereo PCM
device.
This patch removes the "mono,mono" mapping from Behringer UMC22, which
hopefully won't be missed too much (there are still "mono,aux1" and
"aux1,mono" mappings available for mono recording).
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/667>
Alsa UCM device string can contain private configuration prefix required to make
correct device open call. Private prefix is dynamically generated by UCM manager
depending on internal state. Since pulseaudio sink/source port names currently
contain device string, these may change between runs breaking volume database
and module arguments referring to sink/source.
Fix this by skipping UCM private prefix available via `_alibpref` key while
creating UCM mapping name. Mapping object will still contain unmodified
device string for device open call.
See also https://github.com/alsa-project/alsa-ucm-conf/issues/104
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/598>
These two log messages are most likely intended for the path that was
just tried, but they are mistakenly printing the name of the port's
current path. Fix them.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/594>
Recently we found an issue of output volume on speaker and headphone,
they should have their own volume but in practice they share one
output volume.
This issue happens on the laptops which use the ucm2 sof-hda-dsp,
originally the speaker has output volume A while the headphone has the
output volume B, suppose the speaker is the active port at the moment
and the output volume is A, users plug a headphone to the jack and the
headphone becomes the active port, in this process, ucm_set_port()
calls _disdev/_enadev which triggers the io_mixer_callback(), in the
meanwhile, the module_device_restore will restore the headphone's
volume to B, it will call set_volume_cb() to set the volume to B, but
this value is not written to hw immediately, during the time of
waiting for the B to be written to the hw, the io_mixer_callback()
calls get_volume_cb(), it reads hw volume and gets the volume A, then
it overrides the output volume to A, this results in the headphone
gets the volume A instead of B.
If a machine doesn't use the ucm, this issue will not happen since the
set_port_cb() will not trigger the io_mixer_callback(). If the ports
don't belong to the same sink/source, this issue also doesn't happen.
BugLink: http://bugs.launchpad.net/bugs/1930188
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/577>
It seems that in sound context environment variable is not available for
match expression.
This commit utilizes walkthrough to refer to attributes in fw node. The
combination of vendor, model, units is enough to match the node since
the attributes of fw unit doesn't have vendor.
Fix: 37358e42c4 ("alsa: Suppress udev detection of sound card for some units on IEEE 1394 bus")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/566>
This reverts commit 96369919e5.
The commit was originally for the issue of Headphone can't output
sound, that was because the Headphone and Lineout share the 1st alsa
mixer and DAC, but this commit introduced a new issue of the speaker
is not muted after switching to headphone.
A recent merged kernel commit (f48652bbe3ae@linux) could fix the 1st
issue, so we could revert the fix of the 1st issue from PA, then the
2nd issue is fixed automatically.
BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/747
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/553>
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>
