Disabling dB volumes for max_dB < 0 was added in Pulseaudio in 2021,
based on a device which had -128..-127.07 range. However, negative
max_dB is valid value for USB devices, and there are devices that have
it.
Eg. Microsoft LifeChat LX-3000 has
numid=6,iface=MIXER,name='Speaker Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=151,step=0
: values=150,150
| dBminmax-min=-28.37dB,max=-0.06dB
and the dB range seems to be OK. Web search for "The decibel volume
range for element" also gives other hits with seemingly OK looking
ranges.
Don't disable dB volume unless both the max is negative and the range is
suspiciously small. This should still disable it for the device this
check was originally added for.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/447
Link: 10ac01a206
Some ALSA devices have minimum HW volume value that is muted. ALSA
indicates it with SND_CTL_TLV_DB_GAIN_MUTE = -9999999 dB/100 volume dB.
When rounding down to HW volume, we may get this muted value.
When determining splitting of volumes to mixers and soft volume, we
don't want HW mixers to set volume to muted, unless the target volume is
actually muted.
Fix by adding element_ask_unmuted_dB_vol() that rounds up if the asked
rounding mode resulted to mute.
This fixes mic getting muted at low volume despite ALSA reporting the dB
values correctly.
Fixes#4890
FireWire ALSA driver latency is determined by the buffer size and not the
period. Timer-based scheduling is then not really useful on these devices as
the latency is fixed.
In pro-audio profile, enable IRQ scheduling unconditionally for these
devices, so that controlling the latency works properly.
See #4785
Some devices might have nonfunctional 'Pro Audio' sound. This patch adds a
new 'api.acp.disable-pro-audio' option to disable pro-audio profile entirely.
config.h needs to be consistently included before any standard headers
if we ever want to set feature test macros (like _GNU_SOURCE or whatever)
inside. It can lead to hard-to-debug issues without that.
It can also be problematic just for our own HAVE_* that it may define
if it's not consistently made available before our own headers. Just
always include it first, before everything.
We already did this in many files, just not consistently.
Including C headers inside of `extern "C"` breaks use from C++. Hoist
the includes of standard C headers above the block so we don't try
to mangle the stdlib.
I initially tried to scope this with a targeted change but it's too
hard to do correctly that way. This way, we avoid whack-a-mole.
Firefox is working around this in their e21461b7b8b39cc31ba53c47d4f6f310c673ff2f
commit.
Bug: https://bugzilla.mozilla.org/1953080
Some devices have a hardware volume control, but not a dedicated
hardware mute control. In some of these cases, the volume control is
described as having a hardware mute when volume is 0. This is described
in the TLV information of the volume control, when the
SNDRV_CTL_TLVD_DB_SCALE_MUTE flag is set in the TLV structure.
If set, alsa-lib will set the minimum dB value to -99999.99dB, which
can be detected inside PipeWire.
PipeWire can then use this hardware volume control to apply hardware
mute, when set.
In order to be able to set volumes and mutes separately, changing the
volume whilst muted will save the value, but not write it to the
hardware. When the device is unmuted, the saved value will be restored.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
GoXLR Mini has different numbers of channels actually available (21, 23,
or 25) depending on its firmware/etc, but its UCM profile specifies
always 23. The count can then be bigger or smaller than what is actually
available.
Fail a bit more gracefully in the case of too few channels: create all
the split devices specified by the profile. The channels that aren't
actually available in HW just won't get routed anywhere.
ALSA upstream IIUC is saying that the channel counts should be fixed, so
spew warnings that say the UCM profiles are wrong if they look wrong.
Generally ALSA UCM profiles should all work as they're supposed to be
device-specific, so be more noisy when the profile fails to be supported
due to the PCM device failing to open.
Some logging on the probe outcome in failure case also makes
spa-acp-tool etc. log output easier to read.
In SplitPCM mode, Focusrite Scarlett Gen 4 (USB 1235:8218) UCM profile
specifies "CaptureChannels 2" for the Mic1/2 inputs, but
snd_pcm_hw_params_set_channels(2) fails for the HW device.
Fix by not requiring the channel count to be exact for SplitPCM, but
also allow larger numbers of channels than what UCM profile specifies.
When api.alsa.split-enable=true for ACP device, instruct UCM to not
use alsa-lib plugins for SplitPCM devices.
Grab the information from UCM for the intended channel remapping, and
add the splitting information to the nodes emitted.
Session manager can then look at that, and load nodes to do the channel
splitting.
While initializing ALSA cards with UCM, we call pa_alsa_ucm_add_port()
for each UCM device for each UCM verb. This checks if a port has been
already added by name and skips port initialization if it is already
done. Different UCM verbs can have devices with the same name, which
means their port names end up being the same. So, this port creation
step currently is only done for one UCM verb for both UCM devices.
Volume control setup is also part of this process. The UCM devices only
know about the volume mixer information from the UCM verb that they are
defined in, so the volume control setup is done for one UCM verb at a
time. Skipping this setup when a same-named port exists means only the
profiles belonging to the first initialized UCM verb have working
hardware volume control.
Move the volume control setup out of the port initialization block so
that we try to do it every time, therefore for every UCM verb. However,
check that we don't run it twice for the same UCM verb for a port.
In theory, the PlaybackVolume etc. value can be different per-verb
for the same device, so we can't simplify this code to a single volume
setup per port.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/840
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Commit 88bb0bd7cc ("alsa: Allow to augment ucm port properties") adds
icon properties for some common port names, so that GUIs can show a
relevant icon to help disambiguate devices. However, these still do not
show up in pavucontrol, because it shows icons based on mappings'
properties. Add the relevant property to mappings as well.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/839
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
While trying to figure out device subsets that have aren't internally
contain conflicting devices, we walk through all possible subsets and
check each set if it satisfies ConflictingDevices/SupportedDevices
listed in UCM configuration. For a better user experience, we want to
skip subsets that are fully included in another valid subset we will
also generate.
The iterate_device_subsets() function that achieves the former is
intentionally in iterative form to avoid a stack overflow, since it will
walk through 2^n sets. However, the iterate_maximal_device_subsets()
function that skips incomplete sets is in recursive form, as I had
assumed tail-call optimization would take care of the potential problem.
Convert iterate_maximal_device_subsets() to an iterative form, because
the recursion seems to trigger a segfault with more than 16 devices on
PulseAudio. It doesn't seem to happen on PipeWire, but it's better to
not leave it to luck.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/838
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The alsa/acp code already supports getting a user-friendly monitor name
using the EDID-Like Data (ELD) information available from cards that follow
the Intel HDA specification.
This patch adds support for also parsing the SAD fields of the ELD, and
exposing the results as a "iec958.codecs.detected" property on the
corresponding node, which should make it possible to provide more
user-friendly configuration UIs and defaults.
The default value will take effect if the session manager does not set a
different value.
Brief example:
test@test:~/checkouts/pipewire$ pw-dump | grep -E "(iec958.codecs.detected|iec958.codecs)\":"
"iec958.codecs": "[\"PCM\",\"AC3\",\"EAC3\",\"TrueHD\"]",
"iec958.codecs.detected": "[\"PCM\",\"AC3\",\"EAC3\",\"TrueHD\"]",
<after powering on my receiver>
test@test:~/checkouts/pipewire$ pw-dump | grep -E "(iec958.codecs.detected|iec958.codecs)\":"
"iec958.codecs": "[\"PCM\",\"DTS\",\"AC3\",\"EAC3\",\"TrueHD\",\"DTS-HD\"]",
"iec958.codecs.detected": "[\"PCM\",\"DTS\",\"AC3\",\"EAC3\",\"TrueHD\",\"DTS-HD\"]",
Big thanks to Pauli Virtanen <pav@iki.fi>, who also wrote large paths of the
code for this patch.
The properties of the card might overwrite those of the PCM.
For example, the cards's `alsa.id` will be set on the PCM too
since 37a51533e0 ("acp: add more properties for the card").
To avoid that, call `pa_alsa_init_proplist_card()` first
in `pa_alsa_init_proplist_pcm_info()` instead of last.
See #4135
Don't use the api.alsa.soft-mixer option to disable the path selection
but make a new api.alsa.disable-mixer-path.
Disabling the path selection might leave cards unusable after suspend,
so a separate option is a better idea.
See #4311
Add spa_json_begin_array/object to replace
spa_json_init+spa_json_begin_array/object
This function is better because it does not waste a useless spa_json
structure as an iterator. The relaxed versions also error out when the
container is mismatched because parsing a mismatched container is not
going to give any results anyway.
Use snd_ctl_card_info to set some more card properties such as the
alsa.id, alsa.mixer_name and alsa.components.
alsa.id is interesting because it is possible to use udev rules to set a
custom id, which is handy when you have two identical cards in the
system and want to assign unique ids to them.
See #3912
While switching to the Pro Audio profile from a UCM profile, the active
UCM profile is not disabled because the devices may need a UCM verb to
be set before being used. Then, switching away from the Pro profile to a
UCM profile is done by passing the Off profile as the old profile,
instead of the actually-still-enabled UCM profile.
This means the devices from the old UCM profile are kept enabled when we
try to switch to another UCM profile. And the devices to enable may be
conflicting with the still-enabled devices, which will cause failures.
To avoid this, we need to tell the UCM code to disable the profile when
switching away from it. Doing so disables UCM devices and the UCM verb.
Existing code sets the highest priority UCM verb before probing the Pro
profile, so manually enable the same one here as well, instead of
relying on unclean state from whatever profile that was last active.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The hardware controls we track for volume and mute state can change as
part of enabling or disabling the UCM device. This then triggers a
re-sync of our state with the hardware controls, which can e.g. set our
volume to an unwanted value as the result of enabling the device, or set
a hardware control to a wrong value based on our volume while disabling
the device. So these UCM-triggered changes to enable/disable the device
will at best show up on user interfaces and cause confusion, but maybe
even will push the hardware into an unexpected state.
The volume and mute state we set from user interfaces only make sense
when the devices are enabled. They should not be kept in sync with
hardware for inactive UCM devices [1]. Skip the callbacks for reading
and changing volume and mute state if the UCM device is disabled. This
way, the volume/mute controls for sinks/sources are essentially detached
from the hardware controls until the UCM device is re-enabled.
[1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/772#note_1872757
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/772
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The pa_alsa_ucm_set_port() function is passed both a mapping context and
a device port, and both of these refer to their respective UCM device.
While switching over to having one port per mapping per UCM device, I
expected both of these to be the same device struct, so added an assert
checking so.
This assertion gets triggered when we have multiple UCM verbs declaring
the same UCM device name. The root cause here is that the ports' UCM
device references are set once while creating the ports for the card, so
they happen to be those of a specific verb and may not match those from
a different UCM verb's profiles' mappings.
Solving the root cause necessitates a larger refactor. What we actually
assume here is that name of the UCM device is same for both the port and
the UCM context, which ends up always true in practice. For now, replace
the assert with a check and error.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/802
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Some versions of the ALSA libraries run into a segmentation fault when
we query a UCM device/modifier status without first setting a UCM verb.
It's not a reasonable thing to do anyway, so check for this case and
return an error. Also do the check in other helpers.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/801
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The ucm_get_device_property() function adds to each UCM device's
playback_volumes (or capture_volumes) hash map an associated volume
mixer keyed with the UCM verb. These key-value pairs are then iterated
over in various places which assume the key is a profile name. This
assumption is no longer true since we can generate multiple profiles to
use conflicting devices.
A previous commit 45278904167f ("alsa-ucm: Stop conflating profile name
with UCM verb name") fixes some instances of this assumption, but misses
the relation explained above. Fix more instances of misleading
"profile"s where the UCM verb name is actually meant.
Link: 7005eafee3
Fixes: 57295beee1a6 ("alsa-ucm: Stop conflating profile name with UCM verb name")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Although it's a valid UCM configuration to have multiple devices using
the same PlaybackPCM or CapturePCM, it's unclear how PulseAudio should
handle the cases where multiple of these devices are enabled. Some
options I can think of are:
- Merge all devices sharing the same PCM into the same mapping, open
only one PCM substream for this mapping, and add 'combination ports'
that enable combinations of the devices. This has been the case until
recently, although the combination port logic was broken. A problem
with this is that we can't independently control device volumes. We
most likely cannot use hardware volumes either.
- Have one mapping for each device in the same profile, and open one PCM
substream for each mapping. This is the current state, and it fails
when there are fewer substreams than devices. Otherwise it works, but
it's still confusing, as sound directed to a device-specific mapping
might end up playing at multiple devices.
- Make multiple profiles each with combinations of upto-substream-count
devices, and have one mapping/substream per device. This still causes
the confusion mentioned above. And it's likely that the substream
count will almost always be one, where this case degenerates into the
last one.
- Have one mapping for each device in the same profile, but open only
one PCM substream. I assume this is possible with software mixing, but
it is still confusing like the above, and probably less performant.
- Generate multiple profiles each with one of the shared-PCM devices,
again with one mapping/substream for that one device. The trade-off
with this is that we can't use multiple of these devices at the same
time. However, this doesn't have the output device confusion,
combination port's volume problems, or the substream count limitation.
This patch takes a short-cut to achieve the last option, by considering
shared-PCM devices implicitly conflicting with each other.
Link: 45509ff9bc
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
While switching profiles of the same UCM verb, existing code first
disables devices that are only on the first profile to avoid conflicts.
However, it only disables devices, not modifiers. Even worse, modifiers
which have PlaybackPCM/CapturePCM are incorrectly treated as devices and
result in a segmentation fault.
Check what we are disabling, and call the appropriate disable function
for both devices and modifiers. Modifiers are disabled before devices,
because _dismod calls fail when the modifier's supported devices are
disabled.
Link: b74269016c
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
These are mostly the same as the device helpers added in c83b34516929
("alsa-ucm: Add enable, disable, status helpers for devices"), but for
modifiers instead.
Link: b382a00f8b
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Right now we try to add all UCM devices of a verb to a single profile.
But if some devices using different PCMs are configured as conflicting
with one another, we will only be able to utilize one of them, chosen
seemingly based on the order in the UCM config file.
This is not a problem with conflicting devices sharing a PCM, as they
are assigned to the same mapping and the ports mechanism only enables
one of them to be active at a time.
To utilize all devices in a UCM verb even when there are conflicting
devices using different PCMs, calculate subsets of devices which
can be simultaneously used and create a profile for each such set.
Link: 5dd411190d
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
While switching profiles, it was enough to switch UCM verbs since that
disables all enabled UCM devices and every profile had a distinct verb.
However, switching to the current verb does not disable any devices.
To support multiple profiles for a verb we need to explicitly disable
the old profile's devices, since they might be conflicting with the new
profile's devices and will prevent them from being enabled. Compare both
profiles' mappings, and disable the devices not in the new mappings.
Link: e49da7bcd6
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
After previous patches, we should be generating no combination ports, so
we don't need to store multiple modifiers per mapping. Simplify the code
based on this.
Link: 4821a0569e
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
After previous patches, we should be generating no combination ports, so
we don't need to store multiple devices per mapping. Simplify the code
based on this.
Link: 084d70a1e2
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
[Wim: Apply to acp add_profiles() and acp_card_set_profile()]
After previous patches, we should be generating no combination ports, so
we don't need to store multiple devices per port. Simplify the code
based on this.
Link: bf1708213b
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
A previous commit makes mapping names depend on the UCM device name.
Since UCM device names are unique, this means a mapping will at most
have one port and thus no combination ports can be generated.
This removes the dead code in the pa_alsa_ucm_add_ports_combination()
function, unrolls the remaining code in its helper functions that it
used, and renames it to pa_alsa_ucm_add_port() to signal that it no
longer generates combinations.
Link: 0789a8fb76
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
[Wim: Apply to acp add_profiles(), acp_card_set_profile(), compat.h]
