linux-next/sound/core/Kconfig

271 lines
7.6 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0-only
# ALSA soundcard-configuration
config SND_TIMER
tristate
config SND_PCM
tristate
select SND_TIMER if SND_PCM_TIMER
config SND_PCM_ELD
bool
config SND_PCM_IEC958
bool
config SND_DMAENGINE_PCM
tristate
config SND_HWDEP
tristate
config SND_SEQ_DEVICE
tristate
config SND_RAWMIDI
tristate
select SND_SEQ_DEVICE if SND_SEQUENCER != n
ALSA: rawmidi: UMP support This patch adds the support helpers for UMP (Universal MIDI Packet) in ALSA core. The basic design is that a rawmidi instance is assigned to each UMP Endpoint. A UMP Endpoint provides a UMP stream, typically bidirectional (but can be also uni-directional, too), which may hold up to 16 UMP Groups, where each UMP (input/output) Group corresponds to the traditional MIDI I/O Endpoint. Additionally, the ALSA UMP abstraction provides the multiple UMP Blocks that can be assigned to each UMP Endpoint. A UMP Block is a metadata to hold the UMP Group clusters, and can represent the functions assigned to each UMP Group. A typical implementation of UMP Block is the Group Terminal Blocks of USB MIDI 2.0 specification. For distinguishing from the legacy byte-stream MIDI device, a new device "umpC*D*" will be created, instead of the standard (MIDI 1.0) devices "midiC*D*". The UMP instance can be identified by the new rawmidi info bit SNDRV_RAWMIDI_INFO_UMP, too. A UMP rawmidi device reads/writes only in 4-bytes words alignment, stored in CPU native endianness. The transmit and receive functions take care of the input/out data alignment, and may return zero or aligned size, and the params ioctl may return -EINVAL when the given input/output buffer size isn't aligned. A few new UMP-specific ioctls are added for obtaining the new UMP endpoint and block information. As of this commit, no ALSA sequencer instance is attached to UMP devices yet. They will be supported by later patches. Along with those changes, the protocol version for rawmidi is bumped to 2.0.3. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230523075358.9672-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 07:53:24 +00:00
config SND_UMP
tristate
select SND_RAWMIDI
config SND_UMP_LEGACY_RAWMIDI
bool "Legacy raw MIDI support for UMP streams"
depends on SND_UMP
help
This option enables the legacy raw MIDI support for UMP streams.
When this option is set, an additional rawmidi device for the
legacy MIDI 1.0 byte streams is created for each UMP Endpoint.
The device contains 16 substreams corresponding to UMP groups.
config SND_CORE_TEST
tristate "Sound core KUnit test"
depends on KUNIT
select SND_PCM
default KUNIT_ALL_TESTS
help
This options enables the sound core functions KUnit test.
KUnit tests run during boot and output the results to the debug
log in TAP format (https://testanything.org/). Only useful for
kernel devs running KUnit test harness and are not for inclusion
into a production build.
For more information on KUnit and unit tests in general, refer
to the KUnit documentation in Documentation/dev-tools/kunit/.
config SND_COMPRESS_OFFLOAD
tristate
config SND_COMPRESS_ACCEL
bool
config SND_JACK
bool
# enable input device support in jack layer
config SND_JACK_INPUT_DEV
bool
depends on SND_JACK
default y if INPUT=y || INPUT=SND
config SND_OSSEMUL
bool "Enable OSS Emulation"
select SOUND_OSS_CORE
help
This option enables the build of OSS emulation layer.
config SND_MIXER_OSS
tristate "OSS Mixer API"
depends on SND_OSSEMUL
help
To enable OSS mixer API emulation (/dev/mixer*), say Y here
and read <file:Documentation/sound/designs/oss-emulation.rst>.
Many programs still use the OSS API, so say Y.
To compile this driver as a module, choose M here: the module
will be called snd-mixer-oss.
config SND_PCM_OSS
tristate "OSS PCM (digital audio) API"
depends on SND_OSSEMUL
select SND_PCM
help
To enable OSS digital audio (PCM) emulation (/dev/dsp*), say Y
here and read <file:Documentation/sound/designs/oss-emulation.rst>.
Many programs still use the OSS API, so say Y.
To compile this driver as a module, choose M here: the module
will be called snd-pcm-oss.
config SND_PCM_OSS_PLUGINS
bool "OSS PCM (digital audio) API - Include plugin system"
depends on SND_PCM_OSS
default y
help
If you disable this option, the ALSA's OSS PCM API will not
support conversion of channels, formats and rates. It will
behave like most of new OSS/Free drivers in 2.4/2.6 kernels.
config SND_PCM_TIMER
bool "PCM timer interface" if EXPERT
default y
help
If you disable this option, pcm timer will be unavailable, so
those stubs that use pcm timer (e.g. dmix, dsnoop & co) may work
incorrectly.
For some embedded devices, we may disable it to reduce memory
footprint, about 20KB on x86_64 platform.
config SND_HRTIMER
tristate "HR-timer backend support"
depends on HIGH_RES_TIMERS
select SND_TIMER
help
Say Y here to enable HR-timer backend for ALSA timer. ALSA uses
the hrtimer as a precise timing source. The ALSA sequencer code
also can use this timing source.
To compile this driver as a module, choose M here: the module
will be called snd-hrtimer.
config SND_DYNAMIC_MINORS
bool "Dynamic device file minor numbers"
help
If you say Y here, the minor numbers of ALSA device files in
/dev/snd/ are allocated dynamically. This allows you to have
more than 8 sound cards, but requires a dynamic device file
system like udev.
If you are unsure about this, say N here.
config SND_MAX_CARDS
int "Max number of sound cards"
range 4 256
default 32
depends on SND_DYNAMIC_MINORS
help
Specify the max number of sound cards that can be assigned
on a single machine.
config SND_SUPPORT_OLD_API
bool "Support old ALSA API"
default y
help
Say Y here to support the obsolete ALSA PCM API (ver.0.9.0 rc3
or older).
config SND_PROC_FS
bool "Sound Proc FS Support" if EXPERT
depends on PROC_FS
default y
help
Say 'N' to disable Sound proc FS, which may reduce code size about
9KB on x86_64 platform.
If unsure say Y.
config SND_VERBOSE_PROCFS
bool "Verbose procfs contents"
depends on SND_PROC_FS
default y
help
Say Y here to include code for verbose procfs contents (provides
useful information to developers when a problem occurs). On the
other side, it makes the ALSA subsystem larger.
ALSA: control: Use xarray for faster lookups The control elements are managed in a single linked list and we traverse the whole list for matching each numid or ctl id per every inquiry of a control element. This is OK-ish for a small number of elements but obviously it doesn't scale. Especially the matching with the ctl id takes time because it checks each field of the snd_ctl_id element, e.g. the name string is matched with strcmp(). This patch adds the hash tables with Xarray for improving the lookup speed of a control element. There are two xarray tables added to the card; one for numid and another for ctl id. For the numid, we use the numid as the index, while for the ctl id, we calculate a hash key. The lookup is done via a single xa_load() execution. As long as the given control element is found on the Xarray table, that's fine, we can give back a quick lookup result. The problem is when no entry hits on the table, and for this case, we have a slight optimization. Namely, the driver checks whether we had a collision on Xarray table, and do a fallback search (linear lookup of the full entries) only if a hash key collision happened beforehand. So, in theory, the inquiry for a non-existing element might take still time even with this patch in a worst case, but this must be pretty rare. The feature is enabled via CONFIG_SND_CTL_FAST_LOOKUP, which is turned on as default. For simplicity, the option can be turned off only when CONFIG_EXPERT is set ("You are expert? Then you manage 1000 knobs"). Link: https://lore.kernel.org/r/20211028130027.18764-1-tiwai@suse.de Link: https://lore.kernel.org/r/20220609180504.775-1-tiwai@suse.de Link: https://lore.kernel.org/all/cover.1653813866.git.quic_rbankapu@quicinc.com/ Link: https://lore.kernel.org/r/20220610064537.18660-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-06-10 06:45:37 +00:00
config SND_CTL_FAST_LOOKUP
bool "Fast lookup of control elements" if EXPERT
default y
select XARRAY_MULTI
help
This option enables the faster lookup of control elements.
It will consume more memory because of the additional Xarray.
If you want to choose the memory footprint over the performance
inevitably, turn this off.
config SND_DEBUG
bool "Debug"
help
Say Y here to enable ALSA debug code.
config SND_DEBUG_VERBOSE
bool "More verbose debug"
depends on SND_DEBUG
help
Say Y here to enable extra-verbose debugging messages.
Let me repeat: it enables EXTRA-VERBOSE DEBUGGING messages.
So, say Y only if you are ready to be annoyed.
config SND_PCM_XRUN_DEBUG
bool "Enable PCM ring buffer overrun/underrun debugging"
default n
depends on SND_DEBUG && SND_VERBOSE_PROCFS
help
Say Y to enable the PCM ring buffer overrun/underrun debugging.
It is usually not required, but if you have trouble with
sound clicking when system is loaded, it may help to determine
the process or driver which causes the scheduling gaps.
config SND_CTL_INPUT_VALIDATION
bool "Validate input data to control API"
help
Say Y to enable the additional validation for the input data to
each control element, including the value range checks.
An error is returned from ALSA core for invalid inputs without
passing to the driver. This is a kind of hardening for drivers
that have no proper error checks, at the cost of a slight
performance overhead.
config SND_CTL_DEBUG
bool "Enable debugging feature for control API"
ALSA: control: Add verification for kctl accesses The current implementation of ALSA control API fully relies on the callbacks of each driver, and there is no verification of the values passed via API. This patch is an attempt to improve the situation slightly by adding the validation code for the values stored via info and get callbacks. The patch adds a new kconfig, CONFIG_SND_CTL_VALIDATION. It depends on CONFIG_SND_DEBUG and off as default since the validation would require a slight overhead including the additional call of info callback at each get callback invocation. When this config is enabled, the values stored by each info callback invocation are verified, namely: - Whether the info type is valid - Whether the number of enum items is non-zero - Whether the given info count is within the allowed boundary Similarly, the values stored at each get callback are verified as well: - Whether the values are within the given range - Whether the values are aligned with the given step - Whether any further changes are seen in the data array over the given info count The last point helps identifying a possibly invalid data type access, typically a case where the info callback declares the type being SNDRV_CTL_ELEM_TYPE_ENUMERATED while the get/put callbacks store the values in value.integer.value[] array. When a validation fails, the ALSA core logs an error message including the device and the control ID, and the API call also returns an error. So, with the new validation turned on, the driver behavior difference may be visible on user-space, too -- it's intentional, though, so that we can catch an error more clearly. The patch also introduces a new ctl access type, SNDRV_CTL_ELEM_ACCESS_SKIP_CHECK. A driver may pass this flag with other access bits to indicate that the ctl element won't be verified. It's useful when a driver code is specially written to access the data greater than info->count size by some reason. For example, this flag is actually set now in HD-audio HDMI codec driver which needs to clear the data array in the case of the disconnected monitor. Also, the PCM channel-map helper code is slightly modified to avoid the false-positive hit by this validation code, too. Link: https://lore.kernel.org/r/20200104083556.27789-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-04 08:35:56 +00:00
depends on SND_DEBUG
help
Say Y to enable the debugging feature for ALSA control API.
It performs the additional sanity-checks for each control element
read access, such as whether the values returned from the driver
are in the proper ranges or the check of the invalid access at
out-of-array areas. The error is printed when the driver gives
such unexpected values.
When you develop a driver that deals with control elements, it's
strongly recommended to try this one once and verify whether you see
any relevant errors or not.
ALSA: control: Add verification for kctl accesses The current implementation of ALSA control API fully relies on the callbacks of each driver, and there is no verification of the values passed via API. This patch is an attempt to improve the situation slightly by adding the validation code for the values stored via info and get callbacks. The patch adds a new kconfig, CONFIG_SND_CTL_VALIDATION. It depends on CONFIG_SND_DEBUG and off as default since the validation would require a slight overhead including the additional call of info callback at each get callback invocation. When this config is enabled, the values stored by each info callback invocation are verified, namely: - Whether the info type is valid - Whether the number of enum items is non-zero - Whether the given info count is within the allowed boundary Similarly, the values stored at each get callback are verified as well: - Whether the values are within the given range - Whether the values are aligned with the given step - Whether any further changes are seen in the data array over the given info count The last point helps identifying a possibly invalid data type access, typically a case where the info callback declares the type being SNDRV_CTL_ELEM_TYPE_ENUMERATED while the get/put callbacks store the values in value.integer.value[] array. When a validation fails, the ALSA core logs an error message including the device and the control ID, and the API call also returns an error. So, with the new validation turned on, the driver behavior difference may be visible on user-space, too -- it's intentional, though, so that we can catch an error more clearly. The patch also introduces a new ctl access type, SNDRV_CTL_ELEM_ACCESS_SKIP_CHECK. A driver may pass this flag with other access bits to indicate that the ctl element won't be verified. It's useful when a driver code is specially written to access the data greater than info->count size by some reason. For example, this flag is actually set now in HD-audio HDMI codec driver which needs to clear the data array in the case of the disconnected monitor. Also, the PCM channel-map helper code is slightly modified to avoid the false-positive hit by this validation code, too. Link: https://lore.kernel.org/r/20200104083556.27789-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-04 08:35:56 +00:00
ALSA: jack: implement software jack injection via debugfs This change adds audio jack injection feature through debugfs, with this feature, we could validate alsa userspace changes by injecting plugin or plugout events to the non-phantom audio jacks. With this change, the sound core will build the folders $debugfs_mount_dir/sound/cardN if SND_DEBUG and DEBUG_FS are enabled. And if users also enable the SND_JACK_INJECTION_DEBUG, the jack injection nodes will be built in the folder cardN like below: $tree $debugfs_mount_dir/sound $debugfs_mount_dir/sound ├── card0 │   ├── HDMI_DP_pcm_10_Jack │   │   ├── jackin_inject │   │   ├── kctl_id │   │   ├── mask_bits │   │   ├── status │   │   ├── sw_inject_enable │   │   └── type ... │   └── HDMI_DP_pcm_9_Jack │   ├── jackin_inject │   ├── kctl_id │   ├── mask_bits │   ├── status │   ├── sw_inject_enable │   └── type └── card1 ├── HDMI_DP_pcm_5_Jack │   ├── jackin_inject │   ├── kctl_id │   ├── mask_bits │   ├── status │   ├── sw_inject_enable │   └── type ... ├── Headphone_Jack │   ├── jackin_inject │   ├── kctl_id │   ├── mask_bits │   ├── status │   ├── sw_inject_enable │   └── type └── Headset_Mic_Jack ├── jackin_inject ├── kctl_id ├── mask_bits ├── status ├── sw_inject_enable └── type The nodes kctl_id, mask_bits, status and type are read-only, users could check jack or jack_kctl's information through them. The nodes sw_inject_enable and jackin_inject are directly used for injection. The sw_inject_enable is read-write, users could check if software injection is enabled or not on this jack, and users could echo 1 or 0 to enable or disable software injection on this jack. Once the injection is enabled, the jack will not change by hardware events anymore, once the injection is disabled, the jack will restore the last reported hardware events to the jack. The jackin_inject is write-only, if the injection is enabled, users could echo 1 or 0 to this node to inject plugin or plugout events to this jack. For the detailed usage information on these nodes, please refer to Documentation/sound/designs/jack-injection.rst. Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20210127085639.74954-2-hui.wang@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-01-27 08:56:39 +00:00
config SND_JACK_INJECTION_DEBUG
bool "Sound jack injection interface via debugfs"
depends on SND_JACK && SND_DEBUG && DEBUG_FS
help
This option can be used to enable or disable sound jack
software injection.
Say Y if you are debugging via jack injection interface.
If unsure select "N".
config SND_UTIMER
bool "Enable support for userspace-controlled virtual timers"
depends on SND_TIMER
help
Say Y to enable the support of userspace-controlled timers. These
timers are purely virtual, and they are supposed to be triggered
from userspace. They could be quite useful when synchronizing the
sound timing with userspace applications (for instance, when sending
data through snd-aloop).
config SND_VMASTER
bool
config SND_DMA_SGBUF
def_bool y
depends on X86
config SND_CTL_LED
tristate
select NEW_LEDS if SND_CTL_LED
select LEDS_TRIGGERS if SND_CTL_LED
source "sound/core/seq/Kconfig"