From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 19:31:13 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 TAA08060;
	Thu, 29 Oct 1998 19:27:07 +0100
Date: Thu, 29 Oct 1998 19:27:07 +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: <9810291704.AA15593@servww1.ww.uni-erlangen.de>
Message-ID: <Pine.LNX.3.96.981029184134.29903F-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 Thu, 29 Oct 1998 16:00:26 +0100 (CET), Jaroslav Kysela
> <perex@jcu.cz> said: 
> 
> >> I guess this part is dependent on implementation.
> >> In the case using soundfont samples, the search key must include
> >> keynote and velocity numbers, because soundfont can handle different
> >> samples assigned with own keynote and velocitry ranges even in an
> >> instrument.  Also, if these platforms are supported, the type of MIDI
> >> (GM/GS/XG) and map number should be embedded in the key. 
> 
> > Yep, this is true. Maybe we can assign something like instrument type
> > to instrument structure.
> 
> > There should be six instrument types:
> 
> > 1. ALIAS (pointer to another instrument, handled by abstract layer)
> > 2. SAMPLE (very simple format for MOD players)
> > 3. GM-MIDI
> > 4. GS-MIDI
> > 5. XG-MIDI
> > 6. MT32-MIDI
> 
> OK, let me rewrite the flow of data processing to clarify the
> situation.
> 
> The abstract routine allocates, releases and searches an "instrument"
> structure record for clients for a certain key.
> The instrument search key contains:
> 1. instrument type (listed above)
> 2. instrument number
> 
> The instrument number can contain the following information in the
> case of MIDI instruments:
> 1. MIDI program number
> 2. bank number (for MIDI)
> 3. map number (for GS & XG MIDI)
> Since one byte is enough for each, this may be combined as an
> integer. 
> 
> In the other types, for example SAMPLE, the instrument number should
> be handled as a simple integer index.
> 
> Now here I write some details to support for soundfont format.
> In the case of soundfonts, the returned data is a list of matched
> instruments (not the actual voice parameter records).
> The actual played instruments are determined by further
> pattern-matching of keynote and velocity from this list.
> The lowlevel driver allocates the memory block for real voice
> parameter record differently, and these records are managed by 
> linked-list in the lowlevel driver.  Thus, the instrument structure 
> contains only a starting pointer to this linked-list.

Absolutely true...

> Also, the samples are handled independently from the voice parameter
> list above.  The sample record contains the address of a sample and
> the assigned sample id.  Since the voice parameter record searches the 
> corresponding sample record from this id, it would be useful if the
> abstract functions can handle not only the instrument list but also
> the sample list.

No, sample list isn't very much abstract, but we can have generic routines
to manage list of records with fixed size. I need for InterWave chips (GUS
PnP) - FFFF format - also layer structures:

<instrument> -> <layers> -> <samples>

> BTW,
> 
> > Why you have list for files? I think that file management should be in
> > application level, not driver...
> 
> Well, the file list doesn't mean the actual file, but it contains a
> linked-list of instruments and samples.  Each file list is
> independent, and is never affected by other file lists.
> One reason to use this list is that the driver needs to manage the
> file id to tell the same sample ids in different soundfont files.
> Another reason is the capability of multiple instruments.
> Suppose that you already loaded full MIDI instruments, but want to
> load only a piano additionally.  The new piano is appended on RAM
> (without removing the old piano from RAM), and the instrument list is
> rebuilt.  Then, you want to remove only this piano.  The driver needs
> to rebuild the instrument list from the file list, then the old piano
> appears again in it.

No, this implementation will mistake applications, but file ID (or
something like 64-bit or 128-bit unique instrument ID) should be in
instrument structure for instrument caching.

Example: First application uses some default instruments. They are loaded
to onboard DRAM. First application ends after playing. Second application
uses new piano instrument which will override default piano instrument. 
Default instrument is removed from "search" list, but it is still on
instrument list if is enough DRAM on soundcard. Second application ends
after playing. Third application uses default instruments, too. Driver
exchange new piano and old piano on "search" list, but both instruments
are still in onboard DRAM. Driver can simply compare if instrument is
already in DRAM with comparing of unique instrument ID which will be get 
from instrument manager application. We can add similar IDs for samples
(for sharing).

Search instrument list and instrument list should use same space, only
another link pointers.

Comments, suggestions or other ideas?

						Jaroslav

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


