Differences between version 18 and predecessor to the previous major change of AlsaNotes.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 18 | Last edited on Saturday, June 10, 2006 4:34:06 pm | by AristotlePagaltzis | Revert |
| Older page: | version 17 | Last edited on Tuesday, June 6, 2006 3:10:48 pm | by IanMcDonald | Revert |
@@ -1,160 +1,126 @@
-!!!
[Alsa5.1Notes]
+<b>See also
[Alsa5.1Notes].</b>
-!!! Module hints
-* It may be a good idea to make sure you have the "snd-pcm-oss" module if you want backwards-compatibility
for older apps (see further below). If you are compiling the modules from source, include ''--with-oss=yes'' on your ./configure line
+!!! Application support
for [ALSA]
-* The sound-card on
a Thinkpad 600E needs the snd-cs4236 module, despite the card claiming to
be a 46xx
(and using a module named cs4232 in
the older OSS driver series)
.
+* There is
a version of esd(1) that uses [ALSA] – that means that any app that currently uses esd(1) will
be fine.
(In [Debian]
the [Package] is called <tt>libesd-alsa0</tt>
.)
-* The
sound card
drivers (currently version 1
.0rc2) downloadable from http:
//www.
alsa-project.org appear
to work ok with older alsa libraries (version
.9.6 of alsa-base, alsa-utils, etc
) that are currently in Debian Testing & Unstable.
+* [ALSA] has optional support for [OSS] compatibility for older apps that only know about the [OSS]-style
sound drivers. To use it, make sure the <tt>snd-pcm-oss</tt> module is loaded
. (In Debian, you can just set <tt>startosslayer=true<
/tt> in <tt>/etc/default
/alsa</tt> for the startup scripts
to do this for you
.)
-!!! My sound card doesn't work after an upgrade
-Run the program alsaconf and it will probably fix it.
+!!! Module hints
-!!! Soundblaster SB16 module
-On my LinuxKernel2.6 system, I couldn't load
the alsa
module for the [ISA] SB16 card,
-no matter what I did. Eventually, I discovered it loaded fine
if I disabled the "isapnp"
-option
for the module
. Eg in
<tt>/etc/modprobe
.conf
</tt>, I had
+* It may be a good idea to make sure you have
the <tt>snd-pcm-oss</tt>
module if you want backwards-compatibility
for older apps (see further below)
. If you are compiling the modules from source, include
<tt>--with-oss=yes<
/tt> on your <tt>
./configure
</tt> line.
-<tt> options
snd-sb16 isapnp=
</tt>
+* The sound-card on a Thinkpad 600E needs the
<tt>snd-cs4236
</tt> module, despite the card claiming to be a 46xx (and using a module named cs4232 in the older [OSS] driver series).
-It seemed to be defaulting to trying to use isapnp but that didn't work, whether or not
-I enabled kernel isapnp support and bios PNP support.
+!!! My sound card doesn't work after an upgrade
-!!! Compiling [ALSA] on RedHatLinux
+Run <tt>alsaconf</tt>, it will probably fix it.
-if modprobe(8) complains about unresolved symbols in __schedule_work__, you need to run
-<tt> touch include/linux/workqueue.h</tt>
+!!! Not all sound devices work
-between _
_./configure__ and make
(1)
on __
alsa-driver__
.
+If one of your sound devices doesn't work and you get an error similar to <tt>EMU10K1
_Audigy: probe of 0000:02:0a
.0 failed with error -12<
/tt> then it might be because the devices are fighting over which sound card number they want to be. To fix this alter the sound card module options
(see [Module] page
on how to do this). One example of a configuration that works is <tt>options snd-emu10k1 index=-15</tt>. The <tt>index</tt> parameter specifies which card becomes which number, or if negative then it is a bitmask of numbers that it can be autoassigned to. To learn more about this look at the LinuxKernel source file <tt>Documentation/sound/
alsa/ALSA
-Configuration
.txt</tt>
+!!! Software Mixing With [ALSA]
-!!! Compiling
[ALSA] on RedHatLinux using the FreshRpms [SRPM]
-
-You probably want
to set up your own __
.rpmmacros__ file first,
as per
[RPMNotes]. Remember to specify
the target architecture and the card (see the [
ALSA soundcard matrix
|http://www.
alsa-project
.org/alsa-doc/
] to find yours) to compile for
, eg
.
+You can get
[ALSA] to do software mixing for you without having to resort to something like esd(1)
. This is done via the dmix plugin and
as [documented on
the ALSA wiki
|http://alsa.opensrc
.org/index.php?page=DmixPlugin
]. Basically, you need
to do is get [ALSA] going
, then put the following in a <tt>.asoundrc</tt> file in your home directory
.
<verbatim>
- rpmbuild --rebuild alsa-driver
.x
.y.z-p.src.rpm \
- --define 'cards als4000' --target $arch
-</verbatim>
-
-where __$arch__ might be __athlon__, f.ex. The [RPM]s will end up
in __RPMS/$arch/__, ie f.ex in __RPMS/athlon/__. As with all source builds, you will need to recompile the [SRPM] if you upgrade
your [Kernel]; you only need to install the kernel-module-alsa [RPM], however
.
+#
.asoundrc file
. Put this
in your home directory
.
-!! modprobe(8) complains about unresolved symbols
in ''schedule
_work''
+pcm.mixed {
+ type dmix
+ ipc_key 123456 # Any unique value
+ ipc_key_add_uid true # No idea...
+ slave {
+ pcm "hw:,"
+ # Apparently for OSS emulation device, you have to set the period
+ # and the buffer sizes
in powers of two.
+ period_time
+ period_size 1024 # must be power of 2
+ buffer
_size 4096 # ditto
+ rate 44100
+ }
-You will need to get your hands dirty a bit
. Install
the [SRPM]
:
+ # bindings are cool
. This says, that only
the first
+ # two channels are to be used by dmix, which is enough for
+ # (most) oss apps and also lets multichannel chios work
+ # much faster
:
-<tt
> rpm -ivh alsa-driver.x.y.z-p.src.rpm</tt
>
+ bindings {
+ 0 0 # from 0 =
> to
+ 1 1 # from 1 =
> to 1
+ }
+}
-Now open the __alsa-driver
.x.y.z-p.spec__ in the __SPECS/__ directory, locate the __%configure__ and __make__ commands and add the following command between them
.
+pcm
.!default {
+ type plug
+ slave
.pcm mixed
+}
-<tt> touch include/linux/workqueue
.h</tt>
+pcm
.dsp0 {
+ type plug
+ slave.pcm mixed
+}
-Finally, [RPM] needs to be told to build the ''spec file'':
-
-<verbatim>
- rpmbuild -bb --define 'cards als4000' --target $arch \
- alsa-driver.x.y.z-p.spec
+pcm.mixer0 {
+ type hw
+ card
+}
</verbatim>
-You can now install
the [RPM
]s built in
the __RPMS
/$arch
/__ directory
.
+There are some problems with this. First of all, [OSS] [Kernel] emulation won’t go through this layer. For an [OSS]-based application to use this, you need to use
the <tt>aoss</tt> helper utility. Also, for
[SDL
] based applications (usually games) to use this, you will want
the EnvironmentVariable <tt>AUDIODEV</tt> to be set to <tt>default<
/tt>, ie. <tt>export AUDIODEV=default<
/tt>
.
-!!! Application support for Alsa
-Hints:
-* there is a version of esd that uses alsa - that means that any app that currently uses esd will be fine. (Debian - install libesd-alsa0).
-* alsa has optional support for OSS-compatibility for older apps that only know about the OSS-style sound drivers. To do this, make sure the "snd-pcm-oss"
module is loaded. (In Debian, you can just set "startosslayer=true" in /etc/default/alsa for the start-up scripts to do this for you.)
+!!! Soundblaster SB16
module
-!!! Software Mixing With Alsa
+On my [LinuxKernel2.6] system, I couldn't load the [ALSA] module for the [ISA] SB16 card, no matter what I did. Eventually, I discovered it loaded fine if I disabled the <tt>isapnp</tt> option for the module. Eg in <tt>/etc/modprobe.conf</tt>, I had
-You can get alsa to do software mixing for you without having to resort to something like ESounD. This is done via the dmix plugin and is documented [here|http:
//alsa.opensrc.org/index.php?page=DmixPlugin].
+ <verbatim>
+ options snd-sb16 isapnp=
+ <
/verbatim>
-There are some problems with this. First of all, OSS kernel emulation wont go through this layer. For an OSS-based application
to use this, you need
to use the aoss helper utility. Also, for SDL based applications (usually games)
to use this
, you will want the environment variable AUDIODEV to be set to "default" (export AUDIODEV=default)
.
+It seemed
to be defaulting
to trying
to use <tt>isapnp</tt> but that didn't work
, whether or not I enabled [Kernel] [ISA] [PnP] support and [BIOS] [PnP] support
.
-Basically, all you need to do is get alsa going, then put the following in a .asoundrc file in your home directory.
-<verbatim>
- # .asoundrc file. Put this in your home directory.
- pcm.mixed {
- type dmix
- ipc_key 123456 # Any unique value
- ipc_key_add_uid true # No idea...
- slave {
- pcm "hw:,"
- # Apparently for OSS emulation device, you have to set the period
- # and the buffer sizes
in powers of two.
- period_time
- period_size 1024 # must be power of 2
- buffer
_size 4096 # ditto
- rate 44100
- }
+!!! modprobe(8) complains about unresolved symbols
in <tt>schedule
_work</tt>
- # bindings are cool. This says, that only the first
- # two channels are
to be used by dmix, which is enough for
- # (most) oss apps
and also lets multichannel chios work
- # much faster:
+You need
to run <tt>touch include/linux/workqueue.h</tt> between <tt>./configure</tt>
and <tt>make</tt> on <tt>alsa-driver</tt>.
- bindings {
- 0 0 # from 0 =>
to
- 1 1 #
from 1 => to 1
- }
- }
+If you want
to do this while building
from [SRPM], do the following:
- pcm.!default {
- type plug
- slave.pcm mixed
- }
+Install the [SRPM]:
- pcm.dsp0 {
- type plug
- slave
.pcm mixed
- }
-
- pcm
.mixer0 {
- type hw
- card
- }
+<verbatim>
+rpm -ivh alsa-driver
.x
.y.z-p.src.rpm
</verbatim>
+Now open the <tt>alsa-driver.x.y.z-p.spec</tt> in the <tt>SPECS/</tt> directory, locate the <tt>%configure</tt> and <tt>make</tt> commands and add the following command between them:
+<verbatim>
+touch include/linux/workqueue.h
+</verbatim>
-!!! Playing MIDI files on a SBLive! sound card
-(note - this isn
't really ALSA specific)
+Finally, [RPM] needs to be told to build the
''spec file'':
-You can load "sound fonts" (wave table samples for the midi sequencer) into the sound card
's memory, and then use those to play MIDI files. (Your ALSA drivers must have been built with the
--with
-sequencer=yes configure option
.)
+<verbatim>
+rpmbuild -bb --define 'cards als4000
' --target $arch \
+ alsa-driver.x.y.z
-p
.spec
+</verbatim>
-1)
You need
the "sfxload" program. If you use Debian Woody, it is
in the awe-drv package, otherwise grab it from http:
//mitglied.lycos.de
/iwai/awesfx-.4.4.tar.bz2
-and compile. (It is released under the [GPL]). It is designed for the SB AWE32 and AEW64, but works with SBLive cards too.
-This was recently (March 2004) added to Debian Unstable as the "awesfx" package
.
+You can now install
the [RPM]s built
in the <tt>RPMS
/$arch
/<
/tt> directory
.
-2) Load a "soundfont". The CDROM that came with your soundcard has some... for example, "./sfxload 8mbgmsfx.sf2". You can check that it is loaded into the soundcard's memory by doing "cat /proc/asound/card0/wavetableD1":
- Device: Emu10k1
- Ports: 4
- Addresses: 65:0 65:1 65:2 65:3
- Use Counter: 0
- Max Voices: 64
- Allocated Voices: 0
- Memory Size: 134217728
- Memory Available: 126786844
- Allocated Blocks: 527
- !SoundFonts: 1
- Instruments: 1849
- Samples: 526
- Locked Instruments: 1849
- Locked Samples: 526
-3) Use the "playmidi" program (debian: apt-get install playmidi),
using the "-a" option to tell it to be AWE-compatible:
-<tt>
- $ playmidi -a /path/to/midi/file.mid
-</tt>
+!!! Compiling [ALSA] on RedHatLinux
using the FreshRpms [SRPM]
-Make sure
the volume for
the sequencer isn't muted; in "alsamixer", you are looking for
the slider named "Music"
.
+You probably want to set up your own <tt>.rpmmacros</b> file first, as per [RPMNotes]. Remember to specify
the target architecture and
the card (see
the [ALSA soundcard matrix | http://www.alsa-project.org/alsa-doc/] to find yours) to compile for, eg
.:
-!!Software playback of MIDI files
-You can always install the "timidity" package
- this is a software synthesizer that reads midi files and sends "normal" PCM data to the soundcard, just like an MP3 or OGG playing program would
. Be warned that timidity is a large download as it has lots of samples
.
+<verbatim>
+rpmbuild
--rebuild alsa-driver
.x
.y.z-p.src.rpm \
+ --define 'cards als4000' --target $arch
+</verbatim>
-!!! Problem - not all sound devices work
-If one of your sound devices doesn't work and you get an error similar to
<tt>EMU10K1_Audigy: probe of 0000:02:0a.0 failed with error -12
</tt> then it
might be because the devices are fighting over which sound card number they want to be
. To fix this alter the sound card module options (see
[Module
] page on how to do this). One example of a configuration that works is
<tt>options snd-emu10k1 index=-15
</tt>. The
<tt>index
</tt> parameter specifies which card becomes which number
, or
if negative then it is a bitmask of numbers that it can be autoassigned
to. To learn more about this look at
the LinuxKernel source file
<tt>Documentation/sound/alsa/ALSA
-Configuration.txt
</tt>
+where
<tt>$arch
</tt> might be <tt>athlon</tt>, f
.ex. The
[RPM
]s will end up in
<tt>RPMS/$arch/
</tt>, ie f
.ex in
<tt>RPMS/athlon/
</tt>. As with all source builds
, you will need to recompile the [SRPM]
if you upgrade your [Kernel]; you only need
to install
the <tt>kernel
-module-alsa
</tt> [RPM], however.
