>>>>> On Thu, 03 Dec 1998 14:18:15 +0000, "P.J.Leonard"
<[EMAIL PROTECTED]> said:
> Have you any plans for reuse of memory if samples are released. I
> know that fragmentation will probably limit the usefulness of this
> so I would not put it too high on the priority list :-) At present a
> simply reload everything when I run out of awe memory which works
> OK.
I had a plan to include more effective memory management as you wrote.
The code is already half developed. But I wanted to release the new
version before 2.2 kernel will be shipped, so this development is
stopped now. I'll start it again if I have a time after Christmas.
> Since I talk to the card via OSS I suppose we are stuck with only
> one process talking to the awe32 ? This is a pain because it means
> the patch management must be done from the same process that is
> doing the sequencing.
Yes, I agree with it definitely. I hope ALSA sequencer.
Well, I think of another possibility, now...
Maybe, we can add a proc interface to awedrv, instead of acess via
device file. The proc file is not exclusive, and is read&write for
user space applications. It can be accessed in real time, and be
relatively easily implemented (I suppose).
Looks like not so bad idea...
> What is the status of the AWE w.r.t. ALSA do you have any
> plans/time in this direction ? If so will they cure the decoupling
> of the sequencer and patch management ?
I've tried it, but not successful. So far, I found there're two
obstacles to implement practical drivers and applications on ALSA
sequnecers.
One is the that the patch loading mechanism is not fixed (defined)
yet. Since the ALSA sequencer accepts several aceeses at the same
time, it looks not suitable to load a large bulk data like patch
via the same sequencer device.
And another is that there is no proper way to consult the driver
(aka client) and port with a certain condition. For example, the test
program included in the alsa current release assumes a fixed client
and port number. Originally, it should be assigned by ioctl or
something like that.
The porting of other things, like note-on and off, channel management,
etc. will be not difficult, if we simply implement the present
routines of awedrv/OSS on ALSA.
IMHO, the OSS sequencer emulation is more important than stated in the
ALSA documents, because most of present applications use OSS seq API.
As you know, both API specs are completely different, and ALSA's one
looks a little bit complicated from the viewpoint of application.
Anyway, it's another story...
--
Takashi Iwai / [EMAIL PROTECTED]
Department of Materials Science
Friedrich-Alexander-University Erlangen-Nuernberg
