Takashi Iwai wrote:
>
> Hello,
>
> I updated AWE driver and applications on the web page today.
> The new version includes a new feature, sample sharing.
> This works like caching, and avoids to load the same wave and voice
> twice. It results in saving memory and fast loading speed.
> The new AWElib uses this feature. The performance of dynamic loading
> of new awemidi will be enhanced best if it is built with AWElib.
>
> I originally designed this to use 12MB fonts on my 8MB DRAM card.
> When I listend to only same kind of musics (eg jazz), the loading
> time decreases dramatically.
>
> Several bug fixes are done on awedrv and awelib. XG mapped
> instruments will be loaded properly even in dynamic loading.
> SFVbm works fine now.
>
> The sources and binaries are available on the following URL as always:
> http://bahamut.mm.t.u-tokyo.ac.jp/~iwai/awedrv/
>
> Any bug reports and comments are appreciated.
I look foward to playing with this. I am trying to write some C++
wrappers
for awelib and one of my main concerns was the duplication of samples.
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.
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.
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 ?
all the best Paul.
