File: alsa-base.README.Debian

package info (click to toggle)
alsa-driver 1.0.13-5etch1
  • links: PTS
  • area: main
  • in suites: etch
  • size: 20,108 kB
  • ctags: 50,477
  • sloc: ansic: 319,881; sh: 32,930; makefile: 2,015; python: 1,527; perl: 1,316; xml: 896; awk: 66
file content (150 lines) | stat: -rw-r--r-- 5,537 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
                     alsa-base README.Debian
                     -----------------------

contents
--------
news
loading modules
creating device files
reloading modules after suspension
unloading modules
initscript

news
----
Last updated 16 July 2005


loading modules
---------------
The initscripts in some unstable releases of alsa-base between Debian 3.0
and Debian 3.1 attempted to load ALSA driver modules on boot.  The
initscript in the current alsa-base package does not do this.

You can arrange for ALSA modules to be loaded at boot time by installing
the discover and/or the hotplug package and/or by adding the names of
sound card driver modules to /etc/modules in order of increasing index.

ALSA has a special built-in module autoloading system.  You do not have
to make use of it, and it is useless if your /dev directory is managed by
udev, but in case you do want to use it, here is a brief explanation of
how it is supposed to work.

When the "snd" module is loaded and the user tries to open a sound device
file with a minor number that indicates that card number N is wanted, snd
modprobes "snd-card-N".  Thus, if you set up module loader configuration
file /etc/modutils/sound or /etc/modprobe.d/sound to look like this:

    alias snd-card-0 snd-cs46xx
    options snd-cs46xx index=0

then snd-cs46xx will be automagically loaded when it is needed to handle
the attempted open() of the sound device.  The "index=0" option ensures
that when snd-cs46xx is loaded the first card that it registers is given
index 0.

If you have an additional sound card of the same type then make the file
look like this:

    alias snd-card-0    snd-cs46xx
    alias snd-card-1    snd-cs46xx
    options snd-cs46xx  index=0,1

If you have, instead, an additional sound card of a different type then
make the file look like this:

    alias snd-card-0    snd-cs46xx
    options snd-cs46xx  index=0
    alias snd-card-1    snd-emu10k1
    options snd-emu10k1 index=1

ALSA supports up to eight sound cards.

The alsaconf program, available in the alsa-utils package (in Debian
but not in Ubuntu), performs hardware detection and can write out a
module loader configuration file that looks like the above.

Unfortunately, alsaconf can only detect one sound card and is generally
a poorly written program.  Another way of discovering what module(s)
you need is to install the "discover" package and to run the following
command as root:

  discover --data-path=linux/module/name --data-version=$(uname -r) audio

This will print out the name of the sound card driver module(s) that
are needed.

The module loader configuration files just described are additional to
the files /etc/modutils/alsa-base and /etc/modprobe.d/alsa-base which
are shipped as conffiles with the alsa-base package.  The latter files
(the first of which is used for 2.4 kernels, the second for 2.6 kernels)
contain basic configuration entries which don't normally need to be
customized.  The entries may include:

* ALSA autoloader aliases
* entries that install OSS-emulation and other drivers above drivers
  upon which these depend
* an entry for each normal sound card driver that will cause a command
  to be executed after the driver has initialized
* an entry for each abnormal driver (i.e., a driver that drives
  hardware such as a TV card or modem that is not suited to be the
  primary sound card) preventing it from grabbing index 0

Suppose you decide that you need to load a certain driver, snd-foo,
with options: "dma1=0 ctlport=0x530".  The recommended way to set this
up is to create additional files in /etc/modutils/ and /etc/modprobe.d/
each containing an "options" line:

    # /etc/modutils/alsa_local
    options snd-foo dma1=0 ctlport=0x530

    # /etc/modprobe.d/alsa_local
    options snd-foo dma1=0 ctlport=0x530


creating device files
---------------------
ALSA native device files are located in /dev/snd/.  (ALSA's kernel-
OSS-emulation device files are of course the same as the OSS device
files.)

On a udev system, udev takes care of creating devices files when
modules are loaded.

If you are not using udev then you can create the ALSA device files
manually by running the snddevices program in /usr/share/alsa-base/.
This should have been done for you by alsa-base's post-installation
script.


reloading modules across APM suspend-and-resume
-----------------------------------------------
During suspension many peripherals are switched off; on resuming the
machine these peripherals need to be re-initialized.  Many ALSA
drivers do this properly but some still do not.

If this problem affects you and if your ALSA drivers are built as
loadable modules and your kernel supports module unloading then you
can work around the problem by unloading the driver before suspending
and loading it again after resuming.  This will be done for you
automatically if you add the name of the problematic sound card driver
module to the variable force_unload_modules_before_suspend variable in
/etc/default/alsa.  E.g., if your CS46XX and AZX cards don't work
properly after resuming from APM suspend, add the names of their
driver modules to the list:

    force_unload_modules_before_suspend="snd-cs46xx snd-azx"


unloading modules
-----------------
If you want to unload ALSA driver modules then you will have to stop
all applications that are using ALSA device files.  You can do both
in one step by running:

    /etc/init.d/alsa force-unload

initscript
----------
/etc/init.d/alsa no longer needs to be run on runlevel changes.