AWE64 midi synth driver v0.4.2
- Description
- Latest news
What is needed
- Downloads
Building
Feedback
- Bug reports
Applications
- Applications that can use the driver
- Widi

AWE64 midi synth driver v0.4.2

Description

I hope that parts of this driver will be useful for writing similar drivers. To this end I have separated out the midi emulation code so that it could be made into a module and used by any other driver. The same is true of the soundfont handling code. I would like feedback on these ideas.

Latest news

In ALSA CVS, 3 May 1999

Version 0.4.2, 22 Feb 1999

Version 0.4.1, 16 Feb 1999

Version 0.4.0, 15 Feb 1999

The driver now appears as four ports on one kernel client. This gives you 64 midi channels, and although the hardware only gives you 32 simultaneous voices at most, all the channels can be set to different instruments or whatever.

Routines to connect drivers that use sequencer events, rather than raw midi, are provided.

The MIDI emulation is separated out so that other drivers could use it.

Sustain is added and so now the most common controls are implemented. The framework is there to quickly add the rest.

For more see the changelog.

What is needed

Downloads

The alsa-emu-0.4.2.patch.gz driver source. This is in the form of a patch that can be applied to the current CVS tree of ALSA. I don't think that it will patch the latest release of ALSA so be sure to use an up to date CVS tree. You may find that your browser removes the .gz without actually unzipping it so you have to ungzip it by hand. This only happens from the pipex server.

Source to a slightly modified version of sfxload alsa-sfx.tar.gz or as a patch against sfxload-0.4.2.

Use this playmidi1.c instead of the one in the alsa-lib/testdirectory.

Earlier restrictions on the soundfont you can use no longer apply. But if you don't have a suitable one use GU11-ROM.SF2.gz (as supplied with RedHat).

Building

Apply patch

cd ..where-ever/alsa-driver
patch -p1 < alsa-emu-0.4.2.patch

Driver

	aclocal
	autoconf
	./configure --with-sequencer=yes --with-isapnp=yes --with-debug=full
	make install

--with-cards=sbawe

sfxload

make

Making it work

Load modules as normal
```
modprobe snd-sbawe
```
Load a soundfont. You need to use the very slightly modified sfxload that you downloaded above to do this.
```
sfxload GU11-ROM.SF2
```
There will be a couple of warnings that can be ignored.
Un-mute channels as normal using alsamixer, xamixer, amixer etc. Make sure that the synth output is un-muted and turned up.

Now you should be able to run the test playmidi1 program.

Controls

dd if=/dev/asound/0/patch0 count=1 bs=1

bs=1: Trigger a test note.
bs=2: Connect MIDI-in to the synth. After this command it will be possible to play from a connected keyboard etc.
bs=3: Disconnects from MIDI-in.
bs=4: All notes off. This is now done automatically when the sequencer disconnects, so this is not really needed anymore.

Unloading the modules

dd if=/proc/asound/0/patch0 bs=3 count=1

modprobe -r snd-sbawe

Possible problems and limitations.

It will most likely break if you try to load a font while playing. There is no locking at all between these actions. I haven't actually had a problem, but you were warned. Temporary solution: don't do it.

You can now load a soundfont that uses samples that are stored in RAM. Although it works it is much slower to load than it should be. This is because I can not get the samples to write to RAM reliably. Many samples will write perfectly, but some will have a large number of missing sample points. It is as if sometimes the write address pointer does not increment properly (I saw the same problem on read as well, leading to duplicate words). The only way that I can get it to work is to set the address each time. The OSS driver doesn't do this and seems to work fine so there must be something that I am missing. Any help would be appreciated.

There is not a good method of loading up the sequencer client. Really the user is the only one who can know what should be connected to what. You may or may not want MIDI in to be connected directly to the soundcard. Therefore we need a user utility to determine which client/port combinations are connected together. At present I just have a hack to connect the synth driver to the MIDI-in. Thats all the ddstuff.

I get
```
snd: seq: snd_seq_pool_done() - pool isn't free!!
```
messages when a client disconnects from the synth. I believe that this is harmless, or at least mostly harmless.

Feedback

Bug reports

Design notes

design notes

Changelog

changelog.

Applications

Applications that can use the driver

Widi

http://www.ne.jp/asahi/i/yamahata/widi.

I made this patch to the widi-19990204-SNAP version. This has been applied in the later versions.

You need to set the environment variables to set up the correct clients and ports to talk to. For me this was:

export WIDI_SEQUENCER_ALSA_DEST_QUEUE_A=1
export WIDI_SEQUENCER_ALSA_DEST_CLIENT_A=65
export WIDI_SEQUENCER_ALSA_DEST_PORT_A=0
export WIDI_SEQUENCER_ALSA_DEST_QUEUE_B=1
export WIDI_SEQUENCER_ALSA_DEST_CLIENT_B=65
export WIDI_SEQUENCER_ALSA_DEST_PORT_B=1

WIDI_SEQUENCER_ALSA_DEST_QUEUE

Contents