These shouldn't be enabled by default, because they cannot be
autodetected, and if the configuration is not a supported one, they
produce loud BRRRT at 100% volume and ALSA errors.
`:` is a reserved character on Windows filesystems.
As far as I can tell from looking through both PulseAudio and PipeWire
commit history the files under `alsa/mixer/samples` are not used or
installed by anything.
See #2474.
Currently the HDMI output paths have jack mixers named "HDMI/DP" and
with append-pcm-to-name=true. However, most of the SOC audio drivers
are just named "HDMI" and don't add the ",pcm=N". Add these alternate
jack names to the HDMI audio path files so that jack detection will work
on these SOCs.
It is sometimes useful to add a custom profile-set.
For that, e.g. `default.conf` needs to be modified.
(at least, i have not succeeded in just adding a new file)
But that change gets overridden when the package is updated,
which could be *extremely* dangerous, e.g. if said profile
changed the `volume-limit`.
By shipping an "empty" `9999-custom.conf`,
the update becomes less problematic,
because one can now use e.g. `dpkg-divert` on said file.
Refs. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050293
This is a follow-up to d5390c7, where we switched to the 'PCM' mixer controls
on Sound Blaster Audigy devices, since the ones we used before only work in the
stereo-to-all-speakers mirroring mode.
It turns out we do use that mode after all, but only in a couple of profiles.
Since returning those profiles to the default mixer path yields uneven volume
steps similar to #2934, we instead add a new mixer path just for that mode.
Creative Labs Sound Blaster Audigy cards (snd_emu10k1 driver) expose
mixer controls named 'PCM Front', 'PCM Rear', etc. in addition to the
more common 'Front', 'Rear', etc. The latter seem to be intended for
a stereo-to-all-speakers mirroring mode that we do not use, and have
no effect when we adjust them.
https://docs.kernel.org/sound/cards/audigy-mixer.html
We therefore define a custom mixer path for Audigy devices, using the
PCM mixer controls.
This has been tested on an Audigy 5/Rx. Based on a brief look at the
ALSA driver, I think all Audigy devices (vendor 0x1102, device 0x0004
or 0x0008) have the same PCM controls, making this change probably safe
for our existing Audigy udev rules.
Relevant kernel files:
sound/pci/emu10k1/emu10k1_main.c
sound/pci/emu10k1/emufx.c
include/sound/emu10k1.h
Fixes#2934
According to the alsa-info.txt in the pipewire issues of #747 and #1206,
the Front Playback Volume is shared by Headphone and Lineout or
Headphone and Speaker, But Headphone, Lineout or Speaker they all have
independent Playback Switch, change to only use switch to mute the
Lineout or Speaker. This could resolve the issues of #747 and #1206.
See #1206 and #747
Motu M4 has four inputs (two line-in inputs, and two complete ones
with gain and XLR and whatnot), as well as four outputs (two monitor
pairs, and an unnaccounted headphone).
Sadly, like a few other interfaces, it wasn't being given an input
profile, since the matching code goes through default.conf testing
each config, and ends up selecting 'analog-surround-40', which does
not have input mapping. The inputs would fallback to 'multichannel-
input', which also doesn't have input paths.
Add input paths to all analog-surround-* mappings, and remove their
'direction=output' fields since they handle both out and in.
