linux/sound/drivers/Kconfig

267 lines
8.4 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0-only
config SND_MPU401_UART
tristate
select SND_RAWMIDI
config SND_OPL3_LIB
tristate
select SND_TIMER
select SND_HWDEP
select SND_SEQ_DEVICE if SND_SEQUENCER != n
config SND_OPL4_LIB
tristate
select SND_TIMER
select SND_HWDEP
select SND_SEQ_DEVICE if SND_SEQUENCER != n
# select SEQ stuff to min(SND_SEQUENCER,SND_XXX)
config SND_OPL3_LIB_SEQ
def_tristate SND_SEQUENCER && SND_OPL3_LIB
select SND_SEQ_MIDI_EMUL
select SND_SEQ_MIDI_EVENT
config SND_OPL4_LIB_SEQ
def_tristate SND_SEQUENCER && SND_OPL4_LIB
select SND_SEQ_MIDI_EMUL
select SND_SEQ_MIDI_EVENT
config SND_VX_LIB
tristate
select FW_LOADER
select SND_HWDEP
select SND_PCM
config SND_AC97_CODEC
tristate
select SND_PCM
select AC97_BUS
select SND_VMASTER
menuconfig SND_DRIVERS
bool "Generic sound devices"
default y
help
Support for generic sound devices.
if SND_DRIVERS
config SND_PCSP
tristate "PC-Speaker support (READ HELP!)"
depends on PCSPKR_PLATFORM && X86 && HIGH_RES_TIMERS
depends on INPUT
select SND_PCM
help
If you don't have a sound card in your computer, you can include a
driver for the PC speaker which allows it to act like a primitive
sound card.
This driver also replaces the pcspkr driver for beeps.
You can compile this as a module which will be called snd-pcsp.
WARNING: if you already have a soundcard, enabling this
driver may lead to a problem. Namely, it may get loaded
before the other sound driver of yours, making the
pc-speaker a default sound device. Which is likely not
what you want. To make this driver play nicely with other
sound driver, you can add this in a configuration file under
/etc/modprobe.d/ directory:
options snd-pcsp index=2
You don't need this driver if you only want your pc-speaker to beep.
You don't need this driver if you have a tablet piezo beeper
in your PC instead of the real speaker.
Say N if you have a sound card.
Say M if you don't.
Say Y only if you really know what you do.
config SND_DUMMY
tristate "Dummy (/dev/null) soundcard"
select SND_PCM
help
Say Y here to include the dummy driver. This driver does
nothing, but emulates various mixer controls and PCM devices.
You don't need this unless you're testing the hardware support
of programs using the ALSA API.
To compile this driver as a module, choose M here: the module
will be called snd-dummy.
config SND_ALOOP
tristate "Generic loopback driver (PCM)"
select SND_PCM
select SND_TIMER
help
Say 'Y' or 'M' to include support for the PCM loopback device.
This module returns played samples back to the user space using
the standard ALSA PCM device. The devices are routed 0->1 and
1->0, where first number is the playback PCM device and second
number is the capture device. Module creates two PCM devices and
configured number of substreams (see the pcm_substreams module
parameter).
The loopback device allows time synchronization with an external
timing source using the time shift universal control (+-20%
of system time).
To compile this driver as a module, choose M here: the module
will be called snd-aloop.
ALSA: Implement the new Virtual PCM Test Driver We have a lot of different virtual media drivers, which can be used for testing of the userspace applications and media subsystem middle layer. However, all of them are aimed at testing the video functionality and simulating the video devices. For audio devices we have only snd-dummy module, which is good in simulating the correct behavior of an ALSA device. I decided to write a tool, which would help to test the userspace ALSA programs (and the PCM middle layer as well) under unusual circumstances to figure out how they would behave. So I came up with this Virtual PCM Test Driver. This new Virtual PCM Test Driver has several features which can be useful during the userspace ALSA applications testing/fuzzing, or testing/fuzzing of the PCM middle layer. Not all of them can be implemented using the existing virtual drivers (like dummy or loopback). Here is what can this driver do: - Simulate both capture and playback processes - Generate random or pattern-based capture data - Inject delays into the playback and capturing processes - Inject errors during the PCM callbacks Also, this driver can check the playback stream for containing the predefined pattern, which is used in the corresponding selftest to check the PCM middle layer data transferring functionality. Additionally, this driver redefines the default RESET ioctl, and the selftest covers this PCM API functionality as well. The driver supports both interleaved and non-interleaved access modes, and have separate pattern buffers for each channel. The driver supports up to 4 channels and up to 8 substreams. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230606193254.20791-2-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-07 03:32:53 +08:00
config SND_PCMTEST
tristate "Virtual PCM test driver"
depends on DEBUG_FS
ALSA: Implement the new Virtual PCM Test Driver We have a lot of different virtual media drivers, which can be used for testing of the userspace applications and media subsystem middle layer. However, all of them are aimed at testing the video functionality and simulating the video devices. For audio devices we have only snd-dummy module, which is good in simulating the correct behavior of an ALSA device. I decided to write a tool, which would help to test the userspace ALSA programs (and the PCM middle layer as well) under unusual circumstances to figure out how they would behave. So I came up with this Virtual PCM Test Driver. This new Virtual PCM Test Driver has several features which can be useful during the userspace ALSA applications testing/fuzzing, or testing/fuzzing of the PCM middle layer. Not all of them can be implemented using the existing virtual drivers (like dummy or loopback). Here is what can this driver do: - Simulate both capture and playback processes - Generate random or pattern-based capture data - Inject delays into the playback and capturing processes - Inject errors during the PCM callbacks Also, this driver can check the playback stream for containing the predefined pattern, which is used in the corresponding selftest to check the PCM middle layer data transferring functionality. Additionally, this driver redefines the default RESET ioctl, and the selftest covers this PCM API functionality as well. The driver supports both interleaved and non-interleaved access modes, and have separate pattern buffers for each channel. The driver supports up to 4 channels and up to 8 substreams. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230606193254.20791-2-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-07 03:32:53 +08:00
select SND_PCM
help
Say 'Y' or 'M' to include support for the Virtual PCM test driver.
This driver is aimed at extended testing of the userspace applications
which use the ALSA API, as well as the PCM middle layer testing.
It can generate random or pattern-based data into the capture stream,
check the playback stream for containing the selected pattern, inject
time delays during capture/playback, redefine the RESET ioctl operation
to perform the PCM middle layer testing and inject errors during the
PCM callbacks. It supports both interleaved and non-interleaved access
modes. You can find the corresponding selftest in the 'alsa'
selftests folder.
config SND_VIRMIDI
tristate "Virtual MIDI soundcard"
depends on SND_SEQUENCER
select SND_TIMER
select SND_RAWMIDI
select SND_SEQ_VIRMIDI
select SND_SEQ_MIDI_EVENT
help
Say Y here to include the virtual MIDI driver. This driver
allows to connect applications using raw MIDI devices to
sequencer clients.
If you don't know what MIDI is, say N here.
To compile this driver as a module, choose M here: the module
will be called snd-virmidi.
config SND_MTPAV
tristate "MOTU MidiTimePiece AV multiport MIDI"
depends on HAS_IOPORT
select SND_RAWMIDI
help
To use a MOTU MidiTimePiece AV multiport MIDI adapter
connected to the parallel port, say Y here and make sure that
the standard parallel port driver isn't used for the port.
To compile this driver as a module, choose M here: the module
will be called snd-mtpav.
config SND_MTS64
tristate "ESI Miditerminal 4140 driver"
depends on PARPORT
select SND_RAWMIDI
help
The ESI Miditerminal 4140 is a 4 In 4 Out MIDI Interface with
additional SMPTE Timecode capabilities for the parallel port.
Say 'Y' to include support for this device.
To compile this driver as a module, chose 'M' here: the module
will be called snd-mts64.
config SND_SERIAL_U16550
tristate "UART16550 serial MIDI driver"
depends on HAS_IOPORT
select SND_RAWMIDI
help
To include support for MIDI serial port interfaces, say Y here
and read <file:Documentation/sound/cards/serial-u16550.rst>.
This driver works with serial UARTs 16550 and better.
This driver accesses the serial port hardware directly, so
make sure that the standard serial driver isn't used or
deactivated with setserial before loading this driver.
To compile this driver as a module, choose M here: the module
will be called snd-serial-u16550.
config SND_SERIAL_GENERIC
tristate "Generic serial MIDI driver"
depends on SERIAL_DEV_BUS
depends on OF
select SND_RAWMIDI
help
To include support for mapping generic serial devices as raw
ALSA MIDI devices, say Y here. The driver only supports setting
the serial port to standard baudrates. To attain the standard MIDI
baudrate of 31.25 kBaud, configure the clock of the underlying serial
device so that a requested 38.4 kBaud will result in the standard speed.
Use this devicetree binding to configure serial port mapping
<file:Documentation/devicetree/bindings/sound/serial-midi.yaml>
To compile this driver as a module, choose M here: the module
will be called snd-serial-generic.
config SND_MPU401
tristate "Generic MPU-401 UART driver"
depends on HAS_IOPORT
select SND_MPU401_UART
help
Say Y here to include support for MIDI ports compatible with
the Roland MPU-401 interface in UART mode.
To compile this driver as a module, choose M here: the module
will be called snd-mpu401.
config SND_PORTMAN2X4
tristate "Portman 2x4 driver"
depends on PARPORT
select SND_RAWMIDI
help
Say Y here to include support for Midiman Portman 2x4 parallel
port MIDI device.
To compile this driver as a module, choose M here: the module
will be called snd-portman2x4.
config SND_AC97_POWER_SAVE
bool "AC97 Power-Saving Mode"
depends on SND_AC97_CODEC
default n
help
Say Y here to enable the aggressive power-saving support of
AC97 codecs. In this mode, the power-mode is dynamically
controlled at each open/close.
The mode is activated by passing 'power_save=X' to the
snd-ac97-codec driver module, where 'X' is the time-out
value, a nonnegative integer that specifies how many
seconds of idle time the driver must count before it may
put the AC97 into power-save mode; a value of 0 (zero)
disables the use of this power-save mode.
After the snd-ac97-codec driver module has been loaded,
the 'power_save' parameter can be set via sysfs as follows:
echo 10 > /sys/module/snd_ac97_codec/parameters/power_save
In this case, the time-out is set to 10 seconds; setting
the time-out to 1 second (the minimum activation value)
isn't recommended because many applications try to reopen
the device frequently. A value of 10 seconds would be a
good choice for normal operations.
See Documentation/sound/designs/powersave.rst for more details.
config SND_AC97_POWER_SAVE_DEFAULT
int "Default time-out for AC97 power-save mode"
depends on SND_AC97_POWER_SAVE
default 0
help
The default time-out value in seconds for AC97 automatic
power-save mode. 0 means to disable the power-save mode.
See SND_AC97_POWER_SAVE for more details.
endif # SND_DRIVERS