2019-05-19 15:07:45 +03:00
# SPDX-License-Identifier: GPL-2.0-only
2008-05-23 18:10:37 +04:00
config SND_MPU401_UART
2019-10-04 17:49:31 +03:00
tristate
select SND_RAWMIDI
2005-04-17 02:20:36 +04:00
2008-05-23 18:10:37 +04:00
config SND_OPL3_LIB
tristate
select SND_TIMER
select SND_HWDEP
ALSA: seq: Allow the modular sequencer registration
Many drivers bind the sequencer stuff in off-load by another driver
module, so that it's loaded only on demand. In the current code, this
mechanism doesn't work when the driver is built-in while the sequencer
is module. We check with IS_REACHABLE() and enable only when the
sequencer is in the same level of build.
However, this is basically a overshoot. The binder code
(snd-seq-device) is an individual module from the sequencer core
(snd-seq), and we just have to make the former a built-in while
keeping the latter a module for allowing the scenario like the above.
This patch achieves that by rewriting Kconfig slightly. Now, a driver
that provides the manual sequencer device binding should select
CONFIG_SND_SEQ_DEVICE in a way as
select SND_SEQ_DEVICE if SND_SEQUENCER != n
Note that the "!=n" is needed here to avoid the influence of the
sequencer core is module while the driver is built-in.
Also, since rawmidi.o may be linked with snd_seq_device.o when
built-in, we have to shuffle the code to make the linker happy.
(the kernel linker isn't smart enough yet to handle such a case.)
That is, snd_seq_device.c is moved to sound/core from sound/core/seq,
as well as Makefile.
Last but not least, the patch replaces the code using IS_REACHABLE()
with IS_ENABLED(), since now the condition meets always when enabled.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-09 16:11:58 +03:00
select SND_SEQ_DEVICE if SND_SEQUENCER != n
2005-04-17 02:20:36 +04:00
2008-05-23 18:10:37 +04:00
config SND_OPL4_LIB
tristate
select SND_TIMER
select SND_HWDEP
ALSA: seq: Allow the modular sequencer registration
Many drivers bind the sequencer stuff in off-load by another driver
module, so that it's loaded only on demand. In the current code, this
mechanism doesn't work when the driver is built-in while the sequencer
is module. We check with IS_REACHABLE() and enable only when the
sequencer is in the same level of build.
However, this is basically a overshoot. The binder code
(snd-seq-device) is an individual module from the sequencer core
(snd-seq), and we just have to make the former a built-in while
keeping the latter a module for allowing the scenario like the above.
This patch achieves that by rewriting Kconfig slightly. Now, a driver
that provides the manual sequencer device binding should select
CONFIG_SND_SEQ_DEVICE in a way as
select SND_SEQ_DEVICE if SND_SEQUENCER != n
Note that the "!=n" is needed here to avoid the influence of the
sequencer core is module while the driver is built-in.
Also, since rawmidi.o may be linked with snd_seq_device.o when
built-in, we have to shuffle the code to make the linker happy.
(the kernel linker isn't smart enough yet to handle such a case.)
That is, snd_seq_device.c is moved to sound/core from sound/core/seq,
as well as Makefile.
Last but not least, the patch replaces the code using IS_REACHABLE()
with IS_ENABLED(), since now the condition meets always when enabled.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-09 16:11:58 +03:00
select SND_SEQ_DEVICE if SND_SEQUENCER != n
2008-05-23 18:10:37 +04:00
2017-06-09 15:40:18 +03:00
# 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
2008-05-23 18:10:37 +04:00
config SND_VX_LIB
tristate
2012-11-22 19:14:55 +04:00
select FW_LOADER
2008-05-23 18:10:37 +04:00
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
2005-04-17 02:20:36 +04:00
2008-03-03 12:53:54 +03:00
config SND_PCSP
2008-05-16 14:10:03 +04:00
tristate "PC-Speaker support (READ HELP!)"
2009-01-30 02:14:46 +03:00
depends on PCSPKR_PLATFORM && X86 && HIGH_RES_TIMERS
2008-04-23 19:08:58 +04:00
depends on INPUT
2008-04-28 14:35:41 +04:00
select SND_PCM
2008-03-03 12:53:54 +03:00
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.
2008-05-16 14:10:03 +04:00
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
2012-03-31 00:37:16 +04:00
sound driver, you can add this in a configuration file under
/etc/modprobe.d/ directory:
2008-05-16 14:10:03 +04:00
options snd-pcsp index=2
2008-03-03 12:53:54 +03:00
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.
2008-05-16 14:10:03 +04:00
Say N if you have a sound card.
Say M if you don't.
Say Y only if you really know what you do.
2008-03-03 12:53:54 +03:00
2005-04-17 02:20:36 +04:00
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.
2010-08-09 16:21:11 +04:00
config SND_ALOOP
2019-10-04 17:49:31 +03:00
tristate "Generic loopback driver (PCM)"
select SND_PCM
2019-11-24 11:39:24 +03:00
select SND_TIMER
2019-10-04 17:49:31 +03:00
help
Say 'Y' or 'M' to include support for the PCM loopback device.
2010-08-09 16:21:11 +04:00
This module returns played samples back to the user space using
the standard ALSA PCM device. The devices are routed 0->1 and
2019-10-04 17:49:31 +03:00
1->0, where first number is the playback PCM device and second
2010-08-09 16:21:11 +04:00
number is the capture device. Module creates two PCM devices and
configured number of substreams (see the pcm_substreams module
2019-10-04 17:49:31 +03:00
parameter).
2010-08-09 16:21:11 +04:00
2021-07-19 13:30:44 +03:00
The loopback device allows time synchronization with an external
2010-08-09 16:21:11 +04:00
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-06 22:32:53 +03:00
config SND_PCMTEST
tristate "Virtual PCM test driver"
2023-08-17 12:37:39 +03:00
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-06 22:32:53 +03: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.
2005-04-17 02:20:36 +04:00
config SND_VIRMIDI
tristate "Virtual MIDI soundcard"
depends on SND_SEQUENCER
select SND_TIMER
select SND_RAWMIDI
2017-06-09 15:40:18 +03:00
select SND_SEQ_VIRMIDI
select SND_SEQ_MIDI_EVENT
2005-04-17 02:20:36 +04:00
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"
2023-05-22 13:50:37 +03:00
depends on HAS_IOPORT
2005-04-17 02:20:36 +04:00
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.
2006-07-27 18:59:23 +04:00
config SND_MTS64
tristate "ESI Miditerminal 4140 driver"
2008-05-23 18:10:37 +04:00
depends on PARPORT
2006-07-27 18:59:23 +04:00
select SND_RAWMIDI
help
The ESI Miditerminal 4140 is a 4 In 4 Out MIDI Interface with
2019-10-04 17:49:31 +03:00
additional SMPTE Timecode capabilities for the parallel port.
2006-07-27 18:59:23 +04:00
Say 'Y' to include support for this device.
To compile this driver as a module, chose 'M' here: the module
2019-10-04 17:49:31 +03:00
will be called snd-mts64.
2006-07-27 18:59:23 +04:00
2005-04-17 02:20:36 +04:00
config SND_SERIAL_U16550
tristate "UART16550 serial MIDI driver"
2023-05-22 13:50:37 +03:00
depends on HAS_IOPORT
2005-04-17 02:20:36 +04:00
select SND_RAWMIDI
help
To include support for MIDI serial port interfaces, say Y here
2018-05-08 21:14:57 +03:00
and read <file:Documentation/sound/cards/serial-u16550.rst>.
2005-04-17 02:20:36 +04:00
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.
2022-05-09 17:59:33 +03:00
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.
2005-04-17 02:20:36 +04:00
config SND_MPU401
tristate "Generic MPU-401 UART driver"
2023-05-22 13:50:37 +03:00
depends on HAS_IOPORT
2005-04-17 02:20:36 +04:00
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.
2007-01-25 15:15:05 +03:00
config SND_PORTMAN2X4
tristate "Portman 2x4 driver"
2008-05-23 18:10:37 +04:00
depends on PARPORT
2007-01-25 15:15:05 +03:00
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.
2008-05-23 18:11:26 +04:00
config SND_AC97_POWER_SAVE
bool "AC97 Power-Saving Mode"
2008-11-28 17:29:01 +03:00
depends on SND_AC97_CODEC
2008-05-23 18:11:26 +04:00
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.
2010-07-15 03:54:21 +04:00
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.
2018-05-08 21:14:57 +03:00
See Documentation/sound/designs/powersave.rst for more details.
2008-05-23 18:11:26 +04:00
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.
2010-07-15 03:54:21 +04:00
See SND_AC97_POWER_SAVE for more details.
2008-05-23 18:10:37 +04:00
endif # SND_DRIVERS