2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2008-05-23 22:10:37 +08:00
|
|
|
config SND_MPU401_UART
|
2019-10-04 22:49:31 +08:00
|
|
|
tristate
|
|
|
|
select SND_RAWMIDI
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-05-23 22:10:37 +08: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 21:11:58 +08:00
|
|
|
select SND_SEQ_DEVICE if SND_SEQUENCER != n
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-05-23 22:10:37 +08: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 21:11:58 +08:00
|
|
|
select SND_SEQ_DEVICE if SND_SEQUENCER != n
|
2008-05-23 22:10:37 +08:00
|
|
|
|
2017-06-09 20:40:18 +08: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 22:10:37 +08:00
|
|
|
config SND_VX_LIB
|
|
|
|
tristate
|
2012-11-22 23:14:55 +08:00
|
|
|
select FW_LOADER
|
2008-05-23 22:10:37 +08: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 06:20:36 +08:00
|
|
|
|
2008-03-03 17:53:54 +08:00
|
|
|
config SND_PCSP
|
2008-05-16 18:10:03 +08:00
|
|
|
tristate "PC-Speaker support (READ HELP!)"
|
2009-01-30 07:14:46 +08:00
|
|
|
depends on PCSPKR_PLATFORM && X86 && HIGH_RES_TIMERS
|
2008-04-23 23:08:58 +08:00
|
|
|
depends on INPUT
|
2008-04-28 18:35:41 +08:00
|
|
|
select SND_PCM
|
2008-03-03 17:53:54 +08: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 18:10:03 +08: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 04:37:16 +08:00
|
|
|
sound driver, you can add this in a configuration file under
|
|
|
|
/etc/modprobe.d/ directory:
|
2008-05-16 18:10:03 +08:00
|
|
|
options snd-pcsp index=2
|
|
|
|
|
2008-03-03 17:53:54 +08: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 18:10:03 +08: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 17:53:54 +08:00
|
|
|
|
2005-04-17 06:20:36 +08: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 20:21:11 +08:00
|
|
|
config SND_ALOOP
|
2019-10-04 22:49:31 +08:00
|
|
|
tristate "Generic loopback driver (PCM)"
|
|
|
|
select SND_PCM
|
2019-11-24 16:39:24 +08:00
|
|
|
select SND_TIMER
|
2019-10-04 22:49:31 +08:00
|
|
|
help
|
|
|
|
Say 'Y' or 'M' to include support for the PCM loopback device.
|
2010-08-09 20:21:11 +08: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 22:49:31 +08:00
|
|
|
1->0, where first number is the playback PCM device and second
|
2010-08-09 20:21:11 +08:00
|
|
|
number is the capture device. Module creates two PCM devices and
|
|
|
|
configured number of substreams (see the pcm_substreams module
|
2019-10-04 22:49:31 +08:00
|
|
|
parameter).
|
2010-08-09 20:21:11 +08:00
|
|
|
|
2021-07-19 18:30:44 +08:00
|
|
|
The loopback device allows time synchronization with an external
|
2010-08-09 20:21:11 +08: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-07 03:32:53 +08:00
|
|
|
config SND_PCMTEST
|
|
|
|
tristate "Virtual PCM test driver"
|
2023-08-17 17:37:39 +08: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-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.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config SND_VIRMIDI
|
|
|
|
tristate "Virtual MIDI soundcard"
|
|
|
|
depends on SND_SEQUENCER
|
|
|
|
select SND_TIMER
|
|
|
|
select SND_RAWMIDI
|
2017-06-09 20:40:18 +08:00
|
|
|
select SND_SEQ_VIRMIDI
|
|
|
|
select SND_SEQ_MIDI_EVENT
|
2005-04-17 06:20:36 +08: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 18:50:37 +08:00
|
|
|
depends on HAS_IOPORT
|
2005-04-17 06:20:36 +08: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 22:59:23 +08:00
|
|
|
config SND_MTS64
|
|
|
|
tristate "ESI Miditerminal 4140 driver"
|
2008-05-23 22:10:37 +08:00
|
|
|
depends on PARPORT
|
2006-07-27 22:59:23 +08:00
|
|
|
select SND_RAWMIDI
|
|
|
|
help
|
|
|
|
The ESI Miditerminal 4140 is a 4 In 4 Out MIDI Interface with
|
2019-10-04 22:49:31 +08:00
|
|
|
additional SMPTE Timecode capabilities for the parallel port.
|
2006-07-27 22:59:23 +08:00
|
|
|
|
|
|
|
Say 'Y' to include support for this device.
|
|
|
|
|
|
|
|
To compile this driver as a module, chose 'M' here: the module
|
2019-10-04 22:49:31 +08:00
|
|
|
will be called snd-mts64.
|
2006-07-27 22:59:23 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config SND_SERIAL_U16550
|
|
|
|
tristate "UART16550 serial MIDI driver"
|
2023-05-22 18:50:37 +08:00
|
|
|
depends on HAS_IOPORT
|
2005-04-17 06:20:36 +08:00
|
|
|
select SND_RAWMIDI
|
|
|
|
help
|
|
|
|
To include support for MIDI serial port interfaces, say Y here
|
2018-05-09 02:14:57 +08:00
|
|
|
and read <file:Documentation/sound/cards/serial-u16550.rst>.
|
2005-04-17 06:20:36 +08: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 22:59:33 +08: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 06:20:36 +08:00
|
|
|
config SND_MPU401
|
|
|
|
tristate "Generic MPU-401 UART driver"
|
2023-05-22 18:50:37 +08:00
|
|
|
depends on HAS_IOPORT
|
2005-04-17 06:20:36 +08: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 20:15:05 +08:00
|
|
|
config SND_PORTMAN2X4
|
|
|
|
tristate "Portman 2x4 driver"
|
2008-05-23 22:10:37 +08:00
|
|
|
depends on PARPORT
|
2007-01-25 20:15:05 +08: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 22:11:26 +08:00
|
|
|
config SND_AC97_POWER_SAVE
|
|
|
|
bool "AC97 Power-Saving Mode"
|
2008-11-28 22:29:01 +08:00
|
|
|
depends on SND_AC97_CODEC
|
2008-05-23 22:11:26 +08: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 07:54:21 +08: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-09 02:14:57 +08:00
|
|
|
See Documentation/sound/designs/powersave.rst for more details.
|
2008-05-23 22:11:26 +08: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 07:54:21 +08:00
|
|
|
See SND_AC97_POWER_SAVE for more details.
|
|
|
|
|
2008-05-23 22:10:37 +08:00
|
|
|
endif # SND_DRIVERS
|