From alsa-devel-owner@alsa.jcu.cz  Mon Nov  2 12:12:18 1998
Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id MAA21038
	for <alsa-devel@jcu.cz>; Mon, 2 Nov 1998 12:11:59 +0100
Received: from servww1.ww.uni-erlangen.de (servww1.ww.uni-erlangen.de [131.188.142.2])
	by faui45.informatik.uni-erlangen.de (8.9.1/8.1.49-FAU) with SMTP id MAA26987
	for <alsa-devel%jcu.cz@faui45.informatik.uni-erlangen.de>; Mon, 2 Nov 1998 12:11:57 +0100 (MET)
Received: from ibm02ww3.ww.uni-erlangen.de by ww.uni-erlangen.de with SMTP;
	id AA11759 (1.37.109.4/7.3m-FAU); Mon, 2 Nov 98 12:11:42 +0100
Message-Id: <9811021111.AA11759@servww1.ww.uni-erlangen.de>
Received: by ibm02ww3.ww.uni-erlangen.de (sSMTP sendmail emulation); Mon, 02 Nov 1998 12:06:36 +0100
To: alsa-devel@jcu.cz
Subject: Re: ALSA sequencer and synth control (Was Re: ALSA + AWE32) 
In-Reply-To: <199810312108.QAA25921@renoir.op.net>
References: <Pine.LNX.3.96.981031151930.30998B-100000@entry.jcu.cz>
	<199810312108.QAA25921@renoir.op.net>
From: "Takashi Iwai" <iwai@ww.uni-erlangen.de>
Date: Mon, 02 Nov 1998 12:06:36 +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

>>>>> On Sat, 31 Oct 1998 16:06:54 -0500, Paul Barton-Davis
<pbd@op.net> said: 

>> OK. Looks we are on same frequency now ;-))

> Well, within 1KHz anyway :) 

> It seems as if your main goals area in the area of sound playback for
> things like games, web plugins and MIDI files. My goals are in the
> area of live music performance, composition and synth programming.

I've read your discussions quite interestingly, but now it looks
scattered over different directions :-)  Well, the first question was: 
Do we need to create other /dev/XXXX files?

My understainding is that ALSA sequencer driver can handle at least
the following:

- communication with multiple clients
- sending data both in real-time and serial queue

Then, if two different clients support for playing back and patch
loading respectively, the user application can send both MIDI
control and patch data separately by specifying the relevant port 
number and encapsulating the data.  The data packet will be routed
through sequencer device correctly to each client in real-time or
queued.  From this approach, all the data can be sent through only
/dev/sndseq without creating any other device files...  Is that right?

The possible problem is the error handling.  How to tell from the
driver to the corresponding user application when an error occurs
immediately?  If the user application has a stupid interface, and it
could handle no longer received data correctly, what happens..?  It
would be nice if there's an ioctl to reset port for such a case.


Now, writing about the instrument handling:  as I wrote before, 
MIDI events and patch loading should be handled separately.
Then, one client accepts MIDI events while another accepts patch-
loading or other device specific events.

However, some exceptional controls like patch-loading are also
necessary.


The schematic flow will be as follows:

	user app
	   V
	ALSA seq ------------+--------------------+
	   V		     |			  V
	MIDI event	   bypassed		patch cache
	layer		     |			loader (if any)
	   V		     V			  |
	device <-------------+--------------------+
	specific driver
	   V
	lowlevel / soundcard
	   V
	device specific
	driver
	   V
	ALSA seq
	   V
	user app

The standard MIDI events will be passed to MIDI event layer. It
receives and process the MIDI events. 
For an intelligent soundcard (like TB), the sequencer client doesn't
have to handle MIDI events directly, but just send it to h/w.
On the other hand, for a non-intelligent wavetable soundcard (like GUS 
and AWE), all the instruments, channels and voices are handled by the
driver.  Then, the device specific driver must be as intelligent
enough as that the hardware on TB does.
In the case of non-intelligent cards, MIDI event layer should be in
kernel in order to communicate with device specific driver frequently
for correct handling of channels and voices.  In the case of
intelligent cards, it may be a user-land client.

Here I wrote a device specific driver, because it accepts events
directly from user applications.  For example, if user app needs to
load the patch to soundcard directly, the patch will be bypassed
(though it's quite h/w dependent).  Other real-time h/w controls can
be sent directly.  This driver needs an FIFO interface, too, then it
should be separated from the lowlevel driver which is in charge of
access to h/w.

The patch loader works to receive a program to play, and load the
patch if it doesn't exist.  It would be pretty nice if this client
supports for caching.  Anyway, this interface should be standarized so 
that user application doesn't need to consider what soundcard it
uses.

We can think of another layer client, for example a simple voice
control used by MOD players.

The above is just my idea.  The corrections appreciated.

-- 
Takashi Iwai / iwai@ww.uni-erlangen.de
Department of Materials Science
Friedrich-Alexander-University Erlangen-Nuernberg

