Hello,
I also though of the problem of memory and patch loading interface.
The main reason is that the older OSS didn't have any ioctl with
sequncer driver for the private data transfer. The application may
receive data from sound driver only via ioctl, although from
application any data can be sent via normal file stream.
But fortunately, the recent OSS/Free-3.8 has a new ioctl for this
purpose. This means that we can build the private API!
(Well, writing private API may lead to a confusion of incompability,
but IMHO it's inevitablly necessary for the better programming...)
I have a plan to rewrite the awedrv largely, especially about patch
loading and handling routines. The samples can be cached on DRAM even
after released. I noticed this necessity when I used chaos 12M fonts
on 8MB DRAM: it takes a few seconds at each time for loaindg fonts
before playing a midi file.
Then, I'd like to open this API spec for discussion.
Of course, it involves with the design of awelib, too.
The both are related closely.
My initial plan is like the following:
- each sample (patch) includes a file id, preset type (GM/GS/XG,etc),
map number (MSB), bank number (LSB), preset number, and keynote (for
drums).
- the sample is handled as individial data, and it can be stored at
arbitrary position of DRAM. The memory block is managed by linked
list (like malloc header).
- the memory block is released only when required: out of left memory,
or the memory-clear command is received.
The application shall access to driver and consult which samples are
preloaded. It can reuse the existing samples as if it's cached, and
load only the necessary patches.
This memory management enables for applications to load temporary
patches without lossing existing samples, and even to replace the
existing samples new one arbitrary.
The combination of different size soundfonts is also interresting.
For example, suppose that 8MB and 2MB (smaller) fonts exists and 2MB
DRAM on board. If 8MB fonts exceed over 2MB DRAM, smaller fonts can
be used as altenative, but still with 8MB fonts as much as possible.
It requires an intelligent management of fonts.
My another interrest is the supplement of XG patchset.
This isn't difficult if the definition of patch record is fixed...
Anyway, please post here if you have any ideas about the new API, what
is required, how to communicate, the data structure, etc.
ps. I wrote a MIDI emulation device for awedrv. This behaves as a
MIDI device but plays on Emu8000. Then, you can play any MIDI files
through this device even if the application doesn't support AWE
specific device but if it supports the normal (external) MIDI device.
I'll upload the source soon on ftp server.
--
Takashi Iwai / [EMAIL PROTECTED]
Department of Materials Science
Friedrich-Alexander-University Erlangen-Nuernberg
