From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 14:16:56 1998
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id OAA17254;
	Thu, 29 Oct 1998 14:16:24 +0100
Date: Thu, 29 Oct 1998 14:16:24 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Takashi Iwai <iwai@ww.uni-erlangen.de>
cc: alsa-devel@jcu.cz
Subject: Re: ALSA + AWE32 
In-Reply-To: <9810291243.AA09300@servww1.ww.uni-erlangen.de>
Message-ID: <Pine.LNX.3.96.981029134953.29367A-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Thu, 29 Oct 1998, Takashi Iwai wrote:

> >>>>> On Wed, 28 Oct 1998 22:00:53 -0500, Paul Barton-Davis
> <pbd@op.net> said: 
> 
> >> It would be also nice separate abstract instrument handling from hardware.
> >> For example - GUS soundcards (and maybe soundcards with Dream chip) have
> >> same problems, too.. I think that instrument handling library should be in
> >> separate module which will call lowlevel code..
> 
> > I don't think instrument handling should be abstracted this far. Once
> > you start messing with some very different soundcards (such as the
> > WaveFront series from TB), you'll get the sense that there isn't much
> > of an abstraction there at all to be encapsulated in a library.
> 
> Agreed.  Actually in my case, the instrument handling routines shares
> only 3% in the whole driver code.  The other parts are something like
> "lowlevel" routines.

OK. I'll try explain what I mean with my above lines...
There are some problems which are similar for all soundcards which have
ability downloading of new samples.

1) soundcard memory allocation routines (bottom routines)
   - allocate block of soundcard memory for one sample (I don't mean
     instrument!!!)

   example:

     int snd_seq_card_mem_clear();
     int snd_seq_card_mem_alloc( struct mem_block **block, int size );
     int snd_seq_card_mem_free( struct mem_block *block );

   Routines should track all allocated blocks which will be removed
   at clear() requests.

2) instrument / sample allocation routines
   - routines which will manage instruments and samples stored in
     soundcard memory (with some dynamic list)

     int snd_seq_card_instr_clear();
     int snd_seq_card_instr_alloc( struct instrument **instr,
                                   int instrno,
				   void *private_data );
     int snd_seq_card_instr_free( struct instrument *instr );
     struct instrument *snd_seq_card_instr_find( int instrno );

   We can even discuss about instrno, in this number should be encoded
   if instrument is MIDI instrument (bank # and program #) or MOD
   instrument (sample).

   In these routines should be also implemented AVL tree for fast search
   of requested samples (the find routine). This is really good if this
   routine will be called within interrupt.

If soundcard is very very different from this model, driver should simply
use own routines for this management...

I mean create library, not interface for all drivers... AWE / GUS / Dream
soundcards should use this library as well...

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic



