http://www.alsa-project.org appear to work ok with older alsa libraries (version 0.9.6 of alsa-base, alsa-utils, etc) that are currently in Debian Testing & Unstable.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.)
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-0.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.
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
Instruments: 1849 Samples: 526 Locked Instruments: 1849 Locked Samples: 526
Make sure the volume for the sequencer isn't muted; in "alsamixer", you are looking for the slider named "Music".
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.
if modprobe(8) complains about unresolved symbols in schedule_work, you need to run
touch include/linux/workqueue.h
between ./configure and make(1) on alsa-driver.
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 to find yours) to compile for, eg.
rpmbuild --rebuild alsa-driver.x.y.z-p.src.rpm \
--define 'cards als4000' --target $arch
where $arch might be athlon, f.ex. The RPMs 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.
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.
touch include/linux/workqueue.h
rpmbuild -bb --define 'cards als4000' --target $arch \
alsa-driver.x.y.z-p.spec
You can now install the RPMs built in the RPMS/$arch/ directory.
Hints:
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.
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).
Basically, all you need to do is get alsa going, then put the following in a .asoundrc file in your home directory.
pcm.mixed {
type dmix ipc_key 123456 # Any unique value ipc_key_add_uid true # No idea... slave {
pcm "hw:0,0"
- Apparently for OSS emulation device, you have to set the period
- and the buffer sizes in powers of two.
period_time 0 period_size 1024 # must be power of 2 buffer_size 4096 # ditto rate 44100
}
- 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:
bindings {
0 0 # from 0 => to 0 1 1 # from 1 => to 1
}
}
pcm.!default {
type plug slave.pcm mixed
}
pcm.dsp0 {
type plug slave.pcm mixed
}
pcm.mixer0 {
type hw card 0
}
3 pages link to AlsaNotes:
