From alsa-devel-owner@alsa.jcu.cz  Wed Oct 28 16:55:23 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 QAA19669
	for <alsa-devel@alsa.jcu.cz>; Wed, 28 Oct 1998 16:54:49 +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 QAA22783
	for <alsa-devel%alsa.jcu.cz@faui45.informatik.uni-erlangen.de>; Wed, 28 Oct 1998 16:54:46 +0100 (MET)
Received: from ibm02ww3.ww.uni-erlangen.de by ww.uni-erlangen.de with SMTP;
	id AA11410 (1.37.109.4/7.3m-FAU); Wed, 28 Oct 98 16:54:40 +0100
Message-Id: <9810281554.AA11410@servww1.ww.uni-erlangen.de>
Received: by ibm02ww3.ww.uni-erlangen.de (sSMTP sendmail emulation); Wed, 28 Oct 1998 16:49:24 +0100
To: alsa-devel@alsa.jcu.cz
Subject: AWE32 synth stuff
From: "Takashi Iwai" <iwai@ww.uni-erlangen.de>
Date: Wed, 28 Oct 1998 16:49:24 +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hello,

(please disregard the last mail I've sent to subscribe...)

After I've read the past logs of this ML today, I've found that the
base part of AWE32 synth stuff can be implemented without too much
difficulties.  Here's my comments and questions for sequnecer
implementations:

* detection of clients:

When one wants to write an application to use a specific
device-client, how to know whether such a client exists, and which
client/port number is it?  Should application check all the client
numbers (ports) by invoking ioctl get_client_info or get_port_info?


* patch management:

I think that separating between patch loader and player makes the
world easy.  Imagine that the samples with 1MB size for each are
trasnferred via /dev/sndseq mixed with other MIDI commands...
I don't believe it's a normal situation.
Also, due to the capability of user-land clients, the patch loader can
access to patch files easilly.

The standard patch (assuming GUS .PAT format) should be accepted via
seqfd.  It'll be useful for MOD player.  However, I can't agree with
the support of other formats via seqfd.  It can be realized by other
clients.

BTW, in the case of AWE32, the real-time patch loading is
unrealistic.  Patch-loading consumes high CPU powers.  Then,
preferrablly all the patches should be preloaded before playing
actually.  It's also another matter for consideration.


* voice allocation:

If the patch manager works, playing MIDI files will be achieved
relatively easilly.  The remaining problem is how to handle the voice
allocation tactics.
For example, OSS AWE driver has several playing modes:
  + each voice is statically linked to a channel (one-to-one)
     -- used by MOD sequncer
  + voices are dynamically allocated to a channel.  multiple voices
    can be assigned to one channel.
     -- used by MIDI sequencer
How to switch this state?


* GM, GS and XG:

Yes, it's a problem that there exist different MIDI formats.
However, all these types can be emulated:  At least, we can try to
play it as similar as possible (not perfectly, but not zero).


* device specific control:

Another question -- the device specific controls should be sent via
sequencer device, or directly from application to device-clients?
Above all, the former is possible (like SEQ_PRIVATE event on OSS)?


Well, I'm a quite newbie for ALSA drivers, so perhaps I wrote some
foolish questions or comments.  I'd appreciate if we discuss about
them.

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

