The ALSA mixer can be opened multiple times (especially for UCM
in the probe). This adds a simple mixer cache to prevent
multiple open calls.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This is just invalid. It results to an error in almost all cases.
The hw:<number> scheme is sufficient to get the right card mixer.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Remove the implicit rule. It is perfectly ok to have the jack with
the same name for another I/O in the driver. Trust only the
value obtained from UCM.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The UCM library is used to get the fallback values from the verbs
and the defaults section. There is no reason to duplicate this code
inside application.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Hardwares without SNDRV_PCM_INFO_RESUME capability, like USB Audio,
don't support snd_pcm_resume() when it's in suspended state.
Let's use snd_pcm_hw_params_can_resume() to check hardware's capability
before snd_pcm_resume() attempt. If it doesn't support resume, just go
to snd_pcm_drop() to leave suspended state directly.
The mixer identifiers should be used for snd_mixer_selem API.
Use them as first, then try to fallback to the raw control
identifiers.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
- sync mixer logic added
- mixer path creation, empty set in mapping creation, paths added in path creation
- path creation moved inside new port creation as it might be called twice otherwise
- some comments added
This allows us to support the PlaybackVolume and CaptureVolume commands
in UCM, specifying a mixer control to use for hardware volume control.
This only works with ports corresponding to single devices at the
moment, and doesn't support stacking controls for combination ports.
The configuration is intended to provide a control (like Headphone
Playback Volume), but we try to resolve to a simple mixer control
(Headphone) to reuse existing volume paths.
On the UCM side, this also requires that when disabling the device for
the port, the volume should be reset to some default.
When enabling/disabling combination devices, things are a bit iffy since
we have no way to reset the volume before switching to a combination
device. It would be nice to have a combination-transition-sequence
command in UCM to handle this and other similar cases.
PlaybackSwitch and CaptureSwitch are yet to be implemented.
It is possible that we might want to have a separate userdata to be used
for these callbacks, so let's split them out.
This is particularly needed when using an pa_rtpoll_item around pa_fdsem
since that uses its own before/after callback but will essentially have
whatever is using the fdsem set up the work callback appropriately (and
thus at least the work callback's userdata needs to be separated from
the before/after callback -- we might as well then just separate all
three).
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
This was being done automatically by autotools, now we need to manually
specify this for each executable/library with a dependency in a
non-standard directory.
Brings things in line with the autotools build, and adds ALSA mixer
paths and profile-sets into the meson build system as well.
The module installation path is also now customisable.
The recent change in ALSA upstream stripped -I$include/alsa path from
pkgconfig. We already fixed for this change in some places but still
the code for UCM was overlooked, and this resulted in the unresolved
symbols in alsa card module. Fix them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Consumers are expected to use <alsa/asoundlib.h> instead of
<asoundlib.h>.
This is in preparation of an change to pkgconfig(alsa) to
not pollute CFLAGS with -I/usr/include/alsa anymore.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Currently, when a system is waking up from suspend, the resume process of the
ALSA sink and source is unstable. Sometimes the device needs to be restarted
multiple times and when the system was suspended between snd_pcm_mmap_begin()
and snd_pcm_mmap_commit(), pulseaudio crashes on resume.
Additionally, variables are not reset after the resume, so that sink/source
report wrong latencies.
This patch fixes the issues by closing and re-opening the PCM if recovery
from an error condition is not possible. Additionally, the variables are
reset, so that latencies are reported correctly.
pa_split_in_place() and pa_split_spaces_in_place() are modifed
to use size_t type instead of integer type.
alsa-ucm.c is revised according to this change.
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
In a former commit 37358e42c4 ("alsa: Suppress udev detection of sound
card for some units on IEEE 1394 bus"), PulseAudio has udev rules to
suppress handling some units on IEEE 1394 bus for a below issue:
Bug 199365 - repeating bus resets on Firewire bus with Focusrite Saffaire 26/io
https://bugzilla.kernel.org/show_bug.cgi?id=199365
However, I found that the rules match another model; Focusrite Liquid
Saffire 56. For detail, refer to below patch for Linux sound subsystem:
[alsa-devel] [PATCH] ALSA: bebob: use more identical mod_alias for
Saffire Pro 10 I/O against Liquid Saffire 56
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/146003.html
For PulseAudio, the udev rule should be improved, because Liquid Saffire 56
(an application of TCAT TCD2200 ASIC, a.k.a Dice Jr.) can be handled by
pulseaudio without the issue.
This commit changes udev rule with model name instead of model_id from
configuration ROM. Below is data on udevd for Liquid Saffire 56, for
your information:
$ udevadm info -q all -p /sys/bus/firewire/devices/fw1.0/sound/card2/
P: /devices/pci0000:00/0000:00:01.2/0000:03:00.2/0000:04:07.0/0000:0a:00.0/0000:0b:00.0/fw1/fw1.0/sound/card2
E: DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:03:00.2/0000:04:07.0/0000:0a:00.0/0000:0b:00.0/fw1/fw1.0/sound/card2
E: ID_BUS=firewire
E: ID_FOR_SEAT=sound-pci-0000_0b_00_0
E: ID_ID=firewire-0x00130e04018001e9
E: ID_MODEL=LIQUID_SAFFIRE_56
E: ID_MODEL_FROM_DATABASE=XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express]
E: ID_MODEL_ID=0x000006
E: ID_PATH=pci-0000:0b:00.0
E: ID_PATH_TAG=pci-0000_0b_00_0
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_INTERFACE_FROM_DATABASE=OHCI
E: ID_PCI_SUBCLASS_FROM_DATABASE=FireWire (IEEE 1394)
E: ID_SERIAL=0x00130e04018001e9
E: ID_SERIAL_SHORT=0x00130e04018001e9
E: ID_VENDOR=Focusrite
E: ID_VENDOR_FROM_DATABASE=Texas Instruments
E: ID_VENDOR_ID=0x00130e
E: SOUND_INITIALIZED=1
E: SUBSYSTEM=sound
E: SYSTEMD_WANTS=sound.target
E: TAGS=💺systemd:
E: USEC_INITIALIZED=9802422583
Fixes: 37358e42c4 ("alsa: Suppress udev detection of sound card for some units on IEEE 1394 bus")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Before this commit ucm_port_contains() was using a strncmp to compare
UCM-device-names without first checking that the part of the port_name
being compared and the device-name have the same length, this was causing
it to return true for both "InternalMic-IN1" and "InternalMic-IN12" when
port_name contained "InternalMic-IN1".
We hit this with the bytcr_rt5651 UCM profile which has "InternalMic-IN1",
"InternalMic-IN2" and "InternalMic-IN12" devices, for devices with their
internal mic connected to IN1, or IN2, or using stereo internal mics
connected to both. This problem resulted in various problems including
the RECMIXL? BST2 switch getting turned on when selecting only
"InternalMic-IN1", as well as confusing the gnome-control-center sound
panel, which could not figure out which device is selected in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The previous commit introduces logic in module-switch-on-port-available
that may change a card's active profile when its availability changes to
PA_AVAILABLE_NO. To choose the new active profile, it needs a consistent
view of the new availability of all profiles, so this commit changes the
order which the ALSA driver updates all profiles' availability to ensure
the active profile is last.
This is not generic enough to cover cases were we may want to take an
action on availability changes of profiles other than the active one
that also need a consistent view of all profiles' availability. But we
don't have any callbacks implementing such action at the moment.
It is helpful to improve reproducibility build [1] since
PA_SRCDIR/PA_BUILDDIR contains build path,
--disable-running-from-build-tree could drop these macros at
precompilation.
[1] https://reproducible-builds.org/
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
