FAQ
From the ALSA wiki
This is an unofficial wiki-based ALSA FAQ (Frequently Asked Questions) that can be freely edited or added to by anyone. If you have some time to spare, please also take a look at those questions that have not been answered yet and answer them if you know the solution (see the articles discussion page).
[edit] General
[edit] Is there an official ALSA FAQ?
Yes, it can be found on the ALSA HOWTO/FAQ page of the ALSA Documents Howto page.
[edit] How do I find out what a word means?
Check out the Category:Glossary page and see if the word is defined there.
[edit] Where can I talk to real people about ALSA if I have questions not answered in the FAQ or other ALSA-documentation?
First of all, check the #alsa channel on irc.freenode.org. Then check the alsa-user and alsa-dev mailing lists [see the ALSA project webpage http://www.alsa-project.org/ for subscription info]
[edit] What's all this dmix/dshare/dsnoop/asym stuff? How does it work?
Well-programmed ALSA apps don't talk to the ALSA kernel modules directly. They leave this job to the ALSA library alsa-lib which is designed to do the high-level stuff. Therefore apps talk to alsa-lib instead of the kernel modules.
alsa-lib now has the ability to offer more devices to the application than just the hardware devices. These additional devices can be defined in one of the config files (the ~/.asoundrc file for per-user settings and other config files for system-wide settings).
alsa-lib also has a list of plugins that can be used in the same way. So, for example it is possible to define a PCM called "foo" which uses the dmix plugin to create a device that is capable of mixing several audio streams in realtime, in software. Similarly, it is also possible (with dshare) to use the 6 channels of a 5.1 card to create 3 virtual stereo devices for example.
See also: .asoundrc, alsa-lib, ALSA plugins, Hardware mixing, Software mixing
[edit] What are the relationships among devices, subdevices, PCM definitions, channels, and speakers? Does a PCM correspond to a device or a subdevice? To a channel?
I'll try to answer this question as well as I can. Please correct me. First take a look at the contents of the file /proc/asound/devices.
On my system it looks like this:
0: [0- 0]: ctl 8: [0- 0]: raw midi 18: [0- 2]: digital audio playback 17: [0- 1]: digital audio playback 16: [0- 0]: digital audio playback 24: [0- 0]: digital audio capture 1: : sequencer 33: : timer 32: [1- 0]: ctl 43: [1- 3]: raw midi 42: [1- 2]: raw midi 41: [1- 1]: raw midi 40: [1- 0]: raw midi
This is the list of devices known on the lowest level, the kernel level. I have got one soundcard cs46xx and the virtual MIDI soundcard virmidi loaded. If you look at the first number in the "[ ]" in the above listing, you will see that there are devices [0- x] and [1- x]. The 0 and 1 correspond to the card which contains this device. Here's the contents of /proc/asound/cards
0 [CS46xx ]: CS46xx - Sound Fusion CS46xx
Sound Fusion CS46xx at 0xcffef000/0xcfe00000, irq 5
1 [VirMIDI ]: VirMIDI - VirMIDI
Virtual MIDI Card 1
So we have card 0 and card 1 and each contains some devices as can be seen from the above contents of /proc/asound/devices. There are different types of devices [digital audio devicess, ctl-devices, midi-devices]. For now, we are only interested in the digital audio devices. It's important to know that applications that use ALSA to play sound usually do not use the kernel modules directly. They rather access the alsa-lib to open PCM-devices. These PCM devices can be either aliases for real hardware devices (digital audio playback and capture devices) on the soundcard or they can be "virtual" devices defined in the plugin layer of alsa-lib.
The user can use a config file .asoundrc to define new PCM devices and to use some of the plugins provided by alsa-lib to configure them. See the DmixPlugin and LADSPA plugins pages for some uses of this. A typical ALSA-installation has many predefined PCM names like "front", "rear", 'surround", etc.. These are mostly aliases for some of the hardware devices on the soundcard. You can also access the hardware devices through alsa-lib via special names. For example "hw:0,0" means: the first digital audio device on the first soundcard. "plughw:1,2" means the third device on the second soundcard but the sample stream is converted to the hardware's native format by alsa-lib first [the "plug" prefix].
PCM devices can have any number of channels. If it's a hardware PCM device then the channel count is determined by the hardware. Depending on the plugin type (see .asoundrc) a PCM device can have any number of channels. It is for example possible to combine several hardware PCM devices into one virtual PCM device with the help of the multi plugin.
I don't know what subdevices are. Please fill this in.
So as you can see from above, a certain PCM can map to many different hardware devices depending on how it is setup. There's not necessarily a correspondance between audio playback and capture devices and the jacks of the soundcard. Depending on the soundcard and how it is setup via alsamixer, the capture device can capture different things: line-in, microphone, the output of the soundcard, etc.
The same is true for the playback devices. Depending on your hardware setup, the playback devices can produce output on different jacks of your soundcard. This is especially true with professional-grade multitrack cards that allow sophisticated routing. On consumer grade cards, the ctl device usually only controls whether to send the audio via the digital out or analog, etc.
[edit] Can I use multiple soundcards with JACK / in sync?
Probably not.
If your soundcard doesn't have a S/PDIF / ADAT / wordclock in then it's basically not possible. Apparently Delta 44 cards can be synced in the kernel, but that's currently only implemented under Windows XP.
If you don't need the cards to run in sync then you can use a MultipleCards asoundrc to configure them to appear as one device, but this will not work with jack, or if you need sample sync between the cards.
If you do have wordclock then linking the wordclock ports (with appropriate t-pieces and terminators) and setting the master/slave controls on the card should lock the clocks and using a MultipleCards asoundrc should make them work as one card.
If you have ADAT or S/PDIF and your card can take its master clock from the input then you might be able to do the same thing, by linking the digital output of the master card to the digital input of the slave card, but if your card does resampling (e.g the Soundblaster Live) it may be difficult, or impossible to persuade it to take its clock from the digital in.
| Note: Many USB audio devices run an second a phase lock loop that is adjusted by the arrival of the USB data packets this information is used to adjust the audio clock to stay in sync. |
[edit] Which soundcard should I buy?
The answer depends on your needs (and your budget).
If you casually listen to music and watch movies in stereo, then sound output built into your motherboard should work fine.
If you professionally mix audio, browse the Alsa Preferred Soundcards list.
If you are an audiophile who wants to utilize surround sound found in movies, or consider yourself a (video) gamer, the Sound Blaster Audigy 4 should suit you.
As of 2007-10-18, the only Linux support for Creatives' X-Fi based sound cards is a closed source beta driver that only works on 64-bit CPUs. Expect Creatives' close source drivers to mature very slowly.
[edit] Obtaining Status Information
[edit] Where are the ALSA drivers installed?
They should be in a subdirectory of your kernel modules directory. On my system that's:
/lib/modules/2.4.22/kernel/sound
It might be different for 2.6 kernels. ALSA modules all start with a "snd-" or "snd_" prefix.
See also: FAQ012
[edit] How can I check whether ALSA works?
First of all, have a look at the output of lsmod. It should show quite a few modules starting with "snd-" or "snd_". This is, of course, only the case if the ALSA modules are not built into the kernel.
The single most important module to be loaded is the driver module for your card. In my case it is the terratec dmx xfire 1024 module [snd-cs46xx]:
tapas@mango:~$ lsmod |grep snd-cs46xx snd-cs46xx 72808 3 snd-ac97-codec 49532 0 [snd-cs46xx] snd-pcm 67168 1 [snd-pcm-oss snd-cs46xx] snd-page-alloc 7028 0 [snd-cs46xx snd-pcm] snd-rawmidi 15456 0 [snd-cs46xx] snd 35460 2 [snd-pcm-oss \ snd-mixer-oss snd-cs46xx snd-ac97-codec snd-pcm snd-rawmidi \ snd-seq-dummy snd-seq snd-timer snd-seq-device]
(the above "snd" line is artifically wrapped, remove the \ chars and put the snd-* items all on one line)
The above command also show which modules snd-cs46xx depends upon. There's quite a few low-level alsa modules, which provide alsas basic infrastructure.
Next thing is to use
cat /proc/asound/version
This should show you the installed ALSA version. If you get an error, chances are that ALSA is not loaded.
If you get an output like:
tapas@mango:~$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.2a. Compiled on Feb 3 2004 for kernel 2.4.22 (SMP) with versioned symbols.
you know that at least the basic ALSA infrastructure is loaded. Next try:
cat /proc/asound/cards
It should show something like this:
tapas@mango:~$ cat /proc/asound/cards
0 [CS46xx ]: CS46xx - Sound Fusion CS46xx
Sound Fusion CS46xx at 0xcffef000/0xcfe00000, irq 5
Of course with your card info. Lastly check /proc/asound/devices for a list of the supported hardware devices on your card[s].
Use the aplay program to test the devices. You need to have a .wav file ready to send to the soundcard. If you don't have a .wav file available you can use mpg123 to convert a .mp3 file to a .wav file; for example, you could use mpg123 -w file.wav file.mp3.
aplay file_name.wav
should play the file via the default pcm-device. If you hear nothing but also do not get an error message, chances are that your sound is just muted. Make sure that "Master" is unmuted using "alsamixer" (use arrow keys and "m") or "alsamixergui" (click on top of the bar). If you get an error message about "permission denied" or similar, then the permissions of the alsa device files are not setup correctly (see ls -l /dev/snd/*). If you get an error message about mismatching sample rates, period sizes, etc, then the wav file you tried to play does not "fit" the PCM device. You can specify a different PCM device via the -D switch. This can be useful to test rear/front outputs or digital outputs:
aplay -Dfront file_name.wav aplay -Drear file_name.wav aplay -Dsurround51 file_name.wav
are some examples. Use aplay -L to list all available PCM devices.
You can also try the speaker-test program to test different setups.
[edit] How can I see whether a channel is muted in alsamixer?
Check for a little "MM" at the top of alsamixer's display. "MM" means the left+right stereo channels are muted. You can toggle muting on or off by pressing the "m" key.
[edit] How can I see which audio [pcm], midi [seq] and mixer [ctl] devices my ALSA installation sees?
Use the information provided by ALSA's /proc interface. Use...
cat /proc/asound/cards
to see which cards are seen by your ALSA installation. Use...
cat /proc/asound/devices
to see which devices these cards have. If you get errors like "No such file or directory" on the above commands, then your ALSA modules are probably not yet loaded. Try browsing in /proc to see which other info your kernel provides. Also check Takashi's explanation of /proc in the AlsaTips page, as well as Proc asound documentation.
In future, /proc will be used for process information only, and the place to look for ALSA info will be sysfs. In the 2.6 kernel source, there's a file called Documentation/filesystems/sysfs.txt with some info about this. You can also use the aadebug script to provide a brief snapshot of your system suitable for emailing to someone else for help.
[edit] How can I find which processes are using Alsa devices?
Short answer: man fuser
Longer answer from Takashi on ALSA mailing-list,
On 2.6 with sysfs:
See /sys/class/sound and check the corresponding devices.
On others:
Check the minor number of each device file and compare with the list on /proc/asound/devices.
Example on 2.6;
# fuser -v /dev/snd/*
USER PID ACCESS COMMAND
/dev/snd/controlC0 admin 7575 f.... kmix
admin 14841 f.... xmms
Also useful might be using lsof:
lsof -n |grep "/dev/snd"
[edit] Configuration
[edit] How can I direct my "digital in" to 5.1 line-in speakers on the same soundcard(Terratec Sound System Aureon 5.1 MK II)?
[edit] How can I enable "digital out" on my soundcard?
Many of the details are explained in DigitalOut. If that doesn't help you, check the documentation for your driver module (kernel source or http://alsa-project.org/alsa-doc/ or driver homepage) and the corresponding wiki page in the ALSA modules section for more info. You may find a page specific to your sound card on the Sound cards page.
[edit] Can I use several applications at once without the second one blocking?
The reason for this is that your soundcard and/or your soundcard driver do not support hardware mixing of multiple streams.
Check the DmixPlugin page and the .asoundrc page for possible remedies. Also see Hardware mixing, software mixing for an overview of the problem.
If the Dmix solution does not remedy the problem there is another less ideal solution:
You may use a Sound Daemon such as Jackit http://jackit.sourceforge.net/, Artsd, or ESD; Sound daemons can connect a number of different audio applications to a single audio device, or they can connect application to application. Those applications must be "made aware" or written in such a way as to take advantage of a sound daemon. Sound daemons will be covered in another FAQ -- It should be noted that artsd is the default sound daemon of the linux window manager KDE and most KDE applications are ARTSD aware and use the daemon to "share" audio. ESD is the default sound daemon of the GNOME desktop and most GNOME applications are ESD aware as well.
| ACTUALIZATION: Check your alsa versions as it says in FAQ047, maybe you do not need an .asoundrc file for this. |
[edit] Every time I boot my computer all volumes are at zero and all channels are muted
Have a look at the alsactl page. Basically the problem is this: every time an ALSA driver is loaded all channels are muted and pulled down to zero by default for safety reasons. If the mixer was left in an undefined state there could be unexpected feedback problems, or worse, damage to your speakers and eardrums. What is the solution then?
ALSA provides a program called alsactl to restore driver and mixer settings. However, you normally don't have to deal with alsactl yourself. ALSA provides a script which can be called at startup and shutdown to do all this for you.
So check if this script is installed properly:
1. Check if the file /etc/init.d/alsasound exists. This should be there even when installing from source and especially when installing from a precompiled package. If not, ALSA may not be properly installed or your distribution may use a different name for the startup script.
2. Check if the following files, or your distribution specific name, exist and are symlinks to /etc/init.d/alsasound (Debian - </code>/etc/init.d/alsa</code>):
/etc/rc0.d/K15alsasound /etc/rc1.d/K15alsasound /etc/rc6.d/K15alsasound /etc/rcS.d/S59alsasound
3. If these files exist and it still doesn't work, reboot your machine and watch the boot messages carefully. If you see a line like this:
ALSA driver is already running.
In this case, check you're boot messages again. Some other boot-up script is pre-loading the ALSA drivers and thusly preventing the alsasound script to load the drivers and the mixer settings. A script known to do this is the hotplug startup script.
There's several ways to fix this. The easiest is to write a script with one line:
alsactl restore
save it as alsasoundrestoremixer in /etc/init.d/, make it executable:
chmod a+x /etc/init.d/alsasoundrestoremixer
and create a symlink to run this straight after alsasound:
ln -s /etc/init.d/alsasoundrestoremixer /etc/rcS.d/S59alsasoundrestoremixer
This forces the loading of the mixer settings every time the system is booted.
It still doesn't work!
Before you consult the mailing list, try this:
- Set your mixer
- Run
alsactl store(This command should save the mixer settings to/etc/asound.state). - Change the mixer settings
- Run
alsactl restore
Did this work? If yes, then I suggest starting again at the top. If this didn't work, check if ALSA is installed properly. If you are using KDE, on startup KDE restores settings saved through the kmix mixer. The state that had been stored by kmix the last time it exited could be different in many cases from what was restored to by alsactl. This may even make custom settings through init scripts or /etc/rc.local useless. So you need to make sure to start kmix once and set the levels/switches to whatever is required and exit kmix correctly. Also, this would only happen if you check 'Enable the Sound System' under 'KDE Control Center -> Sound & Multimedia -> Sound System' and 'Restore Volumes on Login' in 'kmix -> Settings -> Configure Kmix...'.
[edit] How can I update the ALSA version when running a 2.6.x kernel?
If there's a newer kernel version available, it's likely the included ALSA drivers have been updated too. You may find it easier just to download the newer kernel rather than trying to update the ALSA parts inside your existing kernel source code.
If you want to update the ALSA version included with your current kernel, check the AlsaBuild2.6 page.
[edit] ALSA utilities don't work unless I'm root on my Linux system. What's up with that?
This is a very common problem, which may arise when adding a user or installing the operating system from scratch.
When you set up GNU/Linux for the first time, the installer creates a root and a user account for daily usage. Usually, a newly-created user account has very little privileges. Depending on distributions, you may or may not be able to play and record sound using Alsa, unless you add the necessary privileges.
[edit] Needed privileges
The device files in /dev/snd need to be user-readable and user-writable (the tool alsactl is only meant to be run by root though).
Here's the output of ls /dev/snd -l on my system:
tapas@mango:~$ ls /dev/snd/ -l total 0 crw-rw--- 1 root audio 116, 0 Nov 17 04:32 controlC0 crw-rw--- 1 root audio 116, 32 Nov 17 04:32 controlC1 crw-rw--- 1 root audio 116, 64 Nov 17 04:32 controlC2 crw-rw--- 1 root audio 116, 96 Nov 17 04:32 controlC3 crw-rw--- 1 root audio 116, 4 Nov 17 04:32 hwC0D0 crw-rw--- 1 root audio 116, 5 Nov 17 04:32 hwC0D1 crw-rw--- 1 root audio 116, 6 Nov 17 04:32 hwC0D2 ... etc ...
In this setup, the /dev/snd files belong to user root and group audio. The group audio has read-write access (shown by rw above). Therefore, belonging to the group audio is sufficient to use Alsa.
You can use the command groups to see which groups you belong to:
tapas@mango:~$ groups tapas cdrom audio wheel priv
In this example, user tapas is not part of the group audio. Tapas will not be allowed to use Alsa. Poor Tapas!
[edit] Assigning privileges
To add the user tapas to group audio, become root:
su
Type :
adduser tapas audio
Now user tapas will be able to play and record sound using Alsa. Lucky tapas!
[edit] How can I change the default ALSA device?
Ok, if you want to change the default device on your soundcard, you need to edit your ~/.asoundrc file and put something like this into it:
pcm.!default {
type hw
card 0
device 2
}
This selects hw:0,2 as the default device. If you want to do sample-rate conversion, etc, using the plug plugin, you can try this:
pcm.!default {
type plug {
slave.pcm "hw,0,2"
}
}
See also: FAQ026
[edit] Can I play stereo files over all speakers of my 4.0, 5.1 or 7.1 surround-sound setup?
Yes, this Howto describes how you can accomplish this.
[edit] Which is the relationship between ALSA and sound daemons, like ARTS or Esound?
(Will it be possible in the future to replace ARTS and Esound by ALSA, so every program doesn't have to support different sound servers?)
I've seen this confusing question many times in IRC channels so I'll try to give an answer. One part of ALSA is managing the sound devices. Either as module or compiled into the kernel. This means ALSA is really accessing and doing the real control of your soundcard. Look at /proc/asound. It's get confusing with the way ALSA programs are (supposed) to access the hardware. In the past (and unfortunately still) programs accessed a device in /dev directly to talk to the kernel. ALSA has an userland (outside the kernel) library used for accessing the kernel sound devices. This allows software mixing without sound servers for example.
The relation between ALSA and the sound daemons is that the sound servers can access the sound through the ALSA library. In the (perfect) future all programs will use the ALSA library and will be able to replace the sound deamons. But even right now applications are developed for OSS. Note that in a perfect world sound daemons will not be needed in the first place. They are used for software mixing instead of the hardware mixing something soundcards are supposed to do (and cheap cards don't).
| Note: There are updates in cvs to improve the OSS emulation. This should allow all the legacy OSS dameons to share the ALSA sound devices. |
[edit] I cannot record from the microphone
See: Record from mic
[edit] The headphones volume is independent by the master volume, so my keyboard special keys won't affect it. Is there a way to modify this behaviour?
You can change this behaviour by indicating in the file /proc/asound/card0/oss_mixer which is the volume channel. For example when I use internal laptop speakers I use
VOLUME "Master" 0
else
VOLUME "Headphone" 0
You can change this with a simple script like:
#!/bin/bash
STATUS=`less /proc/asound/card0/oss_mixer |grep VOLUME | awk -F " " '{print $2}'`
if [ $STATUS = \"Master\" ]
then
echo "the volume is now controlled by the HEADPHONE"
echo 'VOLUME "Headphone" 0' > /proc/asound/card0/oss_mixer
else
echo "the volume is now controlled by the MASTER"
echo 'VOLUME "Master" 0' > /proc/asound/card0/oss_mixer
fi
This script has to be run sudo since you don't have write acces to /proc/asound/card0/oss_mixer.
But I agree with you it would be better to have a key that maps both channels.
See also: How to use softvol to control the master volume
[edit] How does the move to udev with the 2.6 kernels change the configuration methods?
[edit] How can I create a virtual device that can switch between one of several different soundcards during playback (without interruption)?
It seems like there is no answer to this question (i.e. it's not possible?)
User comment: Why not to use esd for this?
[edit] How can I tell ALSA to swap the left and right stereo channels on my soundcard?
Add this to your ~/.asoundrc file:
pcm.swapped {
type route
slave.pcm "cards.pcm.default"
ttable.0.1 1
ttable.1.0 1
}
Then instruct your program to play to the ALSA PCM device named swapped. If it isn't the default device you want to use, replace cards.pcm.default by the name of your device of choice.
If you want to swap the channels in all applications by default (by making swapped default), just add this line:
pcm.default pcm.swapped
[edit] The order of my cards changes whenever I reboot or as devices are plugged and unplugged. How can I create PCMs that refer to cards by name instead of number?
On the LAU Clemens Ladisch wrote: Make sure that all drivers have the "index" option in /etc/modprobe.conf (or whatever your distribution uses), e.g.:
options snd-intel8x0 index=0 options snd-emu10k1 index=1 options snd-usb-audio index=2,3
Christoph Burger-Scheidlin added: You can refer to the cards by the name that is displayed in the /proc/asound/cards file. My /proc/asound/cards file is...
0 [I82801DBICH4 ]: ICH4 - Intel 82801DB-ICH4
Intel 82801DB-ICH4 with AD1981B at 0x24000800, irq 11
1 [Modem ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
Intel 82801DB-ICH4 Modem at 0x1400, irq 11
and the respective entries in my /etc/asound.conf are:
# CARD DEFINITIONS
pcm.intel { type hw; card I82801DBICH4 }
ctl.intel { type hw; card I82801DBICH4 }
pcm.intelModem { type hw; card Modem }
ctl.intelModem { type hw; card Modem }
[edit] OSS Issues
[edit] Can I use my old OSS apps with ALSA?
Most of the OSS apps work very well with ALSA's kernel-level OSSEmulation [to use this you need to load three ALSA modules snd-pcm-oss , snd-seq-oss and snd-mixer-oss].
However, the OSS sequencer module snd-seq-oss which emulates /dev/sequencer only half works with OSS MIDI sequencers. Recording from MIDI keyboards does not work; it produces MIDI files with corrupted time-values for note-on and note-off events. This is a known bug (see alsa-devel 2004/02/02 2002/8/26 and 2003/12/7'). Playback to MIDI keyboards works ok.
Optionally you can use the aoss script from the alsa-oss package. It has the advantage of being able to use the PCM plugin layer of ALSA. This enables you to use software-mixing for both capture and playback. For more info, see the pages about DmixPlugin, OssEmulation and AlsaTips.
Sometimes problems arise when an app uses mmap'd mode. Check the OssEmulation page for more details and also look at FAQ023.
[edit] Can I have OSS and ALSA modules loaded at the same time?
It depends on whether you mean "OSS modules" to refer to OSS sound driver modules, which are from the old sound driver included in 2.4.x and earlier Linux kernels, or to OSS emulation modules, which are provided in the newer ALSA sound system as a compatible replacement for the old OSS sound driver.
OSS sound driver modules
You can use either 1) modules from the ALSA sound driver or 2) modules from the OSS sound driver, but not both 1) and 2) at the same time. The only sound module that is allowed in the kernel at the same time as the ALSA modules is the "soundcore" module.
OSS emulation modules
Since one of the aims of ALSA is to provide full OSS compatibility for OSS applications, there are OssEmulation modules available in ALSA (if you enable them) which emulate the old OSS sound driver. It is perfectly ok to have any of the three OSS emulation modules snd-pcm-oss and snd-mixer-oss and snd-seq-oss loaded at the same time as the ALSA driver modules because they are actually part of ALSA. They are harmless and do not interfere with the rest of ALSA. If you need ALSA's OSS emulation, load ALSA's OSS emulation modules; if you don't, leave them alone.
Recommended option: load ALSA's OSS emulation modules to emulate the OSS sound driver, and do not use the OSS sound driver modules.
How to tell ALSA modules from OSS driver modules All ALSA modules start with a prefix "snd-" or "snd_". Therefore if you own an emu10k1 based cards and you see "emu10k1" in the output of lsmod [not "snd-emu10k1"], then you have the OSS driver module loaded.. Which is, of course, bad if you want to run ALSA [s.a].
[edit] How can I find out whether I have OSS emulation modules loaded?
To find out whether ALSA's OSS emulation modules are loaded, use these commands (please use cut-and-paste!):
lsmod | awk '$1~/oss/ || NR==1'
If ALSA's OSS emulation modules are loaded, you should see output similar to the following:
Module Size Used by Not tainted snd-seq-oss 24930 0 (autoclean) (unused) snd-mixer-oss 11094 1 (autoclean) [snd-pcm-oss] snd-pcm-oss 38862 0 (autoclean) (unused)
If no OSS emulation modules are loaded, you should see just:
Module Size Used by Not tainted
in which case you may want to load the OSS emulation modules by using the commands:
echo snd-seq-oss snd-pcm-oss snd-mixer-oss | xargs -n 1 modprobe
If that doesn't work, it means you probably do not have OSS emulation enabled in ALSA and will have to recomplile ALSA with the OSS emulation option for the configure script enabled.
If you see no output with the commands above you can look in /proc/asound/oss/sndstat. You should see devices noted below "Audio devices:" if OSS emulation is working.
ALSA's OSS emulation modules are for OSSemulation and provide the OSS devices. They are harmless and do not interfere with the normal operation of ALSA. If you need OSS emulation, load the OSS emulation modules. If you don't, leave them alone.
Don't confuse the ALSA OSS emulation modules with the non-ALSA OSS sound driver modules. See How can I find out whether I have OSS emulation modules loaded? for a full explanation of these modules.
[edit] How can I find out whether I have the OSS sound driver modules loaded?
Use the program lsmod (take a look at its manpage, man lsmod). If you have modules loaded for your soundcard but they do not start with "snd-" then the probability is high that these are OSS modules. Remove them from the kernel using the rmmod command (see man rmmod).
If you get message about the device being busy, make sure you unload the modules in the right order. Also make sure that no application is using sound at the moment of unloaded. You have to eventually kill artsd or esd with the help of the kill command (see man kill).
Ezuk 13/09/04: The above explanation is somewhat vague... "If you have modules loaded for your soundcard..." How am I supposed to tell that they are specifically for my soundcard? How can I know for sure? For instance, I have an lsmod line with "8250". How do I know if this is the OSS module getting in my way, or something entirely different?
[edit] Is there a way to combine more than one alsa device into a single OSS compatible device? For instance a USB Microphone for capture and an onboard soundcard for output that can be accessed as a single OSS compatible device?
Take a look at this example ~/.asoundrc:
pcm.dsp0 {
type plug
slave {
pcm {
type asym
playback.pcm dmix:0
capture.pcm dsnoop:1
}
}
}
Now start your OSS-application with the aoss-wrapper. It should capture from card 1 but output to card 0.
[edit] MIDI
[edit] How can I connect ALSA MIDI-applications?
Use the program aconnect from the alsa-utils package. You can also install one of several graphical alsa-midi patchbay apps [for example: alsa-patch-bay]
[edit] MIDI timing is very unstable. How can I improve that?
[edit] How do I enable MIDI I/O (MPU401 etc.)?
This Question is not about MIDI Synthesis (making MIDI files produce sounds with your Computer Hardware).
Gameport Support (in 2.6 Kernels: Device Drivers/Input Devices Support/Hardware I/O Ports, Gameport Support) must be enabled (M or Y). This is not obvious. For some cards, you might need an additional module, some appear here. Sound/ALSA/Generic devices/Generic MPU-401 driver might be worth a shot.
Even without Gameport Support (even without the necissary modules) Midi devices might appear in /proc/asound/..., /dev/midi might work, no error be visible at all except for that it doesn't work.
See also: MPU-401 MIDI setup (Howto), mpu401
[edit] Troubleshooting
[edit] Nothing works at all. I tried everything!
Try upgrading your ALSA-drivers and/or your kernel.
Alsa is a work in progress and is designed by developers in their spare time (many have day jobs). Although many sound cards work as they should, many are still unsupported or partially supported. This is due in part to either a lack of support from hardware manufactures or lack of time. Please be patient and provide support to other users, and by all means don't give up. ;)
[edit] My ALSA modules seem to be loaded fine but I hear no sound. Why's that?
Play around with alsamixer. The relevant audio channels are probably just muted and/or set to zero or a very quiet volume-level.
On some platforms, particularly the IBM Thinkpad T40 series, the Headphone Jack and/or Line Jack inputs need to be muted in order to hear sound at all. The alsamixer app can do this for you by using the 'm' toggle to mute/unmute. On my system the Headphone Jack appears as the 4th control from the left and is titled "Headphon", the same as the title for the 3rd control (the title is truncated). The same has been observed with SiS SI7012 card, where muting the IEC958 Capture Monitor item helps.
There is also another possibility. Maybe you have many devices that appear as soundcards. One of them may be a modem. Apparently, it can play stuff, but you probably won't hear anything and you certainly don't want to use a modem as the default soundcard.
You can see whether this is your problem by examining /proc/asound/cards. See FAQ026 about how to change your default soundcard, or alias snd-modemmodule off in your /etc/modules.conf.
[edit] Loading my driver module fails with "no such device" (or something similar)
This can have several reasons:
- It is the wrong driver [check the SoundCard matrix from the http://alsa-project.org website to see if you use the correct driver. Also check the ALSA modules and Sound cards pages of this wiki.
- You have specified some incorrect module options. Some soundcards [especiall ISA cards] need to have their DMA, io and irq specified. Check your hardware documentation for the corresponding [jumper] settings.
- The driver is already loaded in the kernel. Check this with the help of the command
lsmod
Attempting to load a driver twice will fail, since the hardware is already occupied by the first driver module. It is possible to load multiple driver modules if you have more than one card of the same type installed.
- You have OSS modules loaded in the kernel. Remove them. See the corresponding FAQ entry
- You have OSS support for your soundcard compiled statically into the kernel. In this case you must recompile your kernel without OSS support. If you want to have OSS available, compile it as modules.
- "No such device" with kernel-2.6.17.8 and VT82C686 AC97 simply means that the builtin alsa driver (version 1.0.11rc4) has a bug. Upgrading to alsa-driver-1.0.12rc3 helps in this case.
[edit] Loading my driver module fails with "unresolved symbols"
This error message means that the module you try to load does not "match" the kernel. Often a version conflict is the cause or modules from a different build than the currently running kernel are used.
If you are building your own ALSA modules from source code and seeing unresolved symbol errors, this could be caused by having old modules in your source tree. See the page "Unresolved Symbols" on this wiki for a fix.
See also: Unresolved Symbols
[edit] I configured dmix but still get unable to open slave or Device or resource busy
If you get something similar
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave snd_pcm_open: Device or resource busy (default)
and you believe that you have dmix plugin active (or you have a recent ALSA driver which activates is automatically) then it is possible that some program uses your /dev/dsp exclusively. The ALSA kernel level OSS emulation does not provide mixing in software.
Another reason might be an ALSA program using a hw device directly. One can override the default device to use dmix (which recent ALSA distributions do), but every program can still again override this default setup and use devices exclusively (one prominent example is jackd which does it on purpose). There's many more programs though that do this, due to programming errors and laziness of the authors coupled with moderately bad ALSA documentation).
For example under Debian/GNU Linux it is possible that you have installed ESD for /dev/dsp instead of ALSA, replace libesd0 with libesd-alsa0.
See also How can I find which processes are using Alsa devices? above. For example:
$ fuser -v /dev/snd/*
USER PID ACCESS COMMAND
/dev/snd/controlC0: username 7960 F.... kmix
username 31509 F.... sh
/dev/snd/pcmC0D0p: username 31509 F.... sh
/dev/snd/timer: username 31509 f.... sh
$ ps f -Awo pid,cmd
(...)
20194 /bin/sh -c /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 62
20195 \_ /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 62
31509 /bin/sh -c /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 69
31510 \_ /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 69
(...)
$ kill 31509 31510 20194 20195
In the above, process 31509 (which had a child process with PID=31510) was blocking access. Killing the blocking processes (if not needed) might restore sound. There may be additional processes (20194, 20195 in the example above) that block. kmix above is the KDE audio mini-mixer.
[edit] My sound crackles when the system is under load. How can I improve that?
There might be a multitude of reasons for this behavior: PCI/ISA interrupt issues, buggy drivers, etc. As a first step you should try updating ALSA, then play around with different slots for the soundcard. Also, in the case of xruns, maybe a kernel with Low-Latency/Preemptible patches might help. Removing uneeded daemons from startup -- look at documentation.
Try to renice processes (make processes more nice):
To renice means to set the priority to a higher or lower level (Give a program more or less execution time). For example if I was using an application like Audacity (Audio Editing) I could do a ps aux | grep audacity and find which process id number was and then do a renice -10 process ID#. This will change the priority of a process higher. Making an application priority higher or lower can mean the difference between good recordings or awful recordings. You may want to lower some priority and make some programs more background in nature (positive numbers can do this).
Try turning off logging (do you need your network monitored every second on your linux multimedia box?):
Linux logs everything. While normally it is not a good idea to turn off loging, it will smooth the system out if you remove any system log daemons (last resort, but works). Audio and video do not "like" things sharing CPU time and linux is not good at scheduling realtime events. In many distributions it is called "services" and it is just a matter of noting which logging "services" are running and remove them (You may want them back later). syslogd is a good example of a logging service.
Give different kernel schedulers a try:
Deadline seems to be the best bet -- I have had the least dropouts with the 2.6.7 kernel with USB MP3+ Soundblaster and several sound processing programs (ecamegapedal, ExEf, and Audacity with Jackdsp running at the same time with Jackit). Try different ones and see what happens. Mileage may very, as with anything.
[edit] My usb-audio device has problems when using sample rates above 22kHz. Why's that?
I am not sure whether it is because of Linux-usb, Alsa or because of the Creative USB Sound Blaster Audigy 2 NX itself, but when you play sounds using a 44.1kHz sample-rate the sound is always crackled. One possible workaround is to force all sounds to play at a 48kHz sample-rate.
An example of a .asoundrc file which does this is: (thx to Florian Schmidt [tapas] for the idea to do so)
pcm.fixed {
type plug
slave {
pcm "hw:1,0"
rate 48000
}
}
Be sure to choose the correct card: hw:1,0 is the 2nd soundcard (soundcards numbering starts from 0), while hw:0,0 would be the first soundcard.
More information about the Creative USB Sound Blaster Audigy 2 NX under linux can be found on my homepage: http://nix.bockb.de. I'll post more information as soon as I get to know more about this issue. (page created: 2004-03-25 19:50 CET by Benjamin Bock [bnjmnbck])
I found another solution that worked for me (a Terratec Aureon 5.1 USB MKII soundcard). Setting the rate to 48000 didn't eliminate the crackles in my speakers. I tried some changes in XMMS (that's where I mainly had the problem) and switching off the Mmap mode worked. I'm using a 5.1 speaker set in duplicate mode (if that's relevant). My e-mail (if you should have any questions about that): coyot_zg@o2.pl
Another option that may improve the situation... I found I had slight crackling when using my Logitech USB Headset on a Lemote Fulong minicomputer running kernel 2.6.18.1, that became almost unbearable when I upgraded to 2.6.21 (running Gentoo/MIPS). I found the following in my /etc/modules.d/alsa (or /etc/modules.conf) helped. This parameter defaults to 8 at time of writing. -- User:Redhatter
options snd-usb-audio nrpacks=1
[edit] "aplay -D rear <soundfile>" fails with "Invalid type for PCM rear definition" What does this error mean? How do you fix it?
Takashi answered:
It means that the alsa-lib doesn't support the rear output of your soundcard yet. Usually it's defined in /usr/share/alsa/cards/*.conf... ok, a bit more explanation for the common cases. This error can appear also when you try "rear" output with the AC97 chip supporting 5.1 output. This is because the AC97 doesn't support the independent rear output. That is, you cannot access only the rear speakers. The rear output is always together with the front (4.0) or the front/center/LFE (5.1). Ditto for "center_lfe" output.
BTW, the individual output is possible by setting up all 5.1 channels and splitting them via dshare plugin. An adventurous user can try that :)
[edit] I am seeing (and hearing) xruns whenever the hard disk is accessed
hdparm -d1 /dev/hda
might help if there are lots of xruns (and you hear noise instead of music) when the hard disk is accessed.
[edit] I get "no such file or directory" errors from all alsa-utils. What's wrong?
If you are sure you have ALSA installed and all necessary modules loaded into the kernel, then one reason could be a version mismatch. Especially version mismatches across major version numbers [like 0.9.7 -> 1.0.2] are bad.
If you're running a 2.6.x ( x <=5 ) series kernel with ALSA compilied into the kernel, you might try running the MAKEDEV.snd script found in the scripts/ directory of your Linux source tree. If the /dev/snd directory is not present, this script will build and populate it with the appropriate devices, which very well might fix your problem. Note: this script must be run as root.
Question from reader: I use ALSA v1.0.8, and a kernel 2.4.20. All the alsa devicefiles in /dev/snd are present. My old OSS applications thru an OSS-emulation layer snd-pcm-oss work properly. But still I can NOT run ANY application from alsa-utils package. What's wrong now? HELP!! The messages are: "Unknown PCM default: no such file or directory" ; "Unknown CLT hw:0,0: no such file or directory" ; and so on...
[edit] Are there any VU meters available for ALSA?
Yes, there are several VU meters for ALSA. Here are some examples:
-
ameter- http://laugeo.free.fr/ameter.html -
ecasignalview- http://www.eca.cx/ecasound - part of Escasound, text based -
meterbridge- http://plugin.org.uk/meterbridge - Not strictly Alsa, works with Jack
[edit] How come my gnome mixer panel has so many sliders in it? I only have a built in AC97 Stereo soundcard?? Where is the docs that describe each slider?
It partially seems to have something to do with loading the OSS emulation drivers in ALSA. If you don't load those, you cut the number of slider panels roughly in half. With OSS you seem to have multiple panels with volume controls for the same hardware. This is a bug that needs to be fixed - send your patches!
[edit] When I use the method in this FAQ to get more than one app play sound at time, all apps plays at 100% volume independently of what is set in alsamixer (or gnome-alsamixer or whichever)
Probably you're using old alsa packages. Try updating alsa-utils and alsa-base to 1.0.9 (alsa-base to 1.0.9b at least). That way, mixing must work without need of .asoundrc file, and if you remove .asoundrc, alsamixer setting will return to work.
If it still plays at 100% volume, try a newer version of the Linux kernel (2.6.14+) or the alsa sources from cvs. If it still does not work with the newest sources, please report your results to the alsa mailing lists.
Thanks to gnubien on #alsa on freenode.net for this response.
[edit] Is there an alsa plugin I can use to compress or normalize my audio output volume?
As a matter of fact you can! You can use LADSPA to "compress" the audio (some people call it normalize), kind of like how the radio stations do it. This pretty much raises all sound to the same level. Handy for, when example, you can't play music too loud and don't want to miss the softer sounds.
It's different from applications like mp3gain because this method dynamically alters the output sound rather than limiting music / audio by its analyzed content.
Read the full thing here: Ladspa_(plugin)
--Voidzero
