From alsa-devel-owner@alsa.jcu.cz  Fri Oct 30 15:33:03 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id PAA29132
	for <alsa-devel@jcu.cz>; Fri, 30 Oct 1998 15:30:34 +0100
Received: from someip.ppp.op.net (d-bm3-19.ppp.op.net [209.152.194.89]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id JAA26496 for <alsa-devel@jcu.cz>; Fri, 30 Oct 1998 09:30:20 -0500 (EST)
Message-Id: <199810301430.JAA26496@renoir.op.net>
To: alsa-devel@jcu.cz
Subject: Re: ALSA sequencer and synth control (Was Re: ALSA + AWE32) 
In-reply-to: Your message of "Thu, 29 Oct 1998 18:28:12 +0100."
             <Pine.LNX.3.96.981029181346.29903A-100000@entry.jcu.cz> 
Date: Fri, 30 Oct 1998 09:28:55 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

I wrote:

>> But lets think about this:
>> 
>>       * a MIDI sequencer generating events roughly every 20msec.
>>       * a patch load request that will take 1-5 secs to complete
>> 
>> So, you route them both to the same device via /dev/sndseq, and what
>> happens ? 
>> 
>> First assume that there is a single driver acting as the sequencer
>> client, and that it takes requests in serial order.  All sound
>> production will stop while the patch load takes place. Not very nice.

Jaroslav said:

>No, this situation should never occur. Maybe you are missing something
>from new sequencer concept:
>
>1) There is priority QUEUE for real-time events.
>2) Priority QUEUE should be bypassed with events without timestamp which
>   can be sent directly to the client.
>3) Each client have own output FIFO.
>
>In your example will be reached this situation:
>
>The sequencer will fill output FIFO for instrument manager client
>(probably user client - application). If FIFO is full, request event will
>be simply lost (last or first - this depends on implementation). The user
>client will get events with instrument requests and put instrument data
>back to sequencer which will use only router to deliver these data
>immediately to the kernel client (this is still instrument manager task,
>so other tasks willn't be touched if downloading takes very much time).

Well, I've been thinking about this overnight, and my first thought is
that you guys are coming at this from a very different direction than
me. My interest isn't in music playback software like mikmod,
playmidi, or various games, all of which want to produce some kind of
pre-defined sonic output.

My interest is in music performance via my Linux system. I use tools
like KeyKit, my own SoftWerk (pattern) sequencer, and other sundry
tools to let me compose and do live performance. The kind of
architecture you're proposing strikes me as needlessly complicated for
this kind of thing.

The obvious question, then, is "is this architecture needlessly
complex for `music playback'" ?

From Jaroslav's comment above, it appears that the flow of control for
instrument loading is like this:

	  application that wants to load a new "instrument"
				  |
				  |
				  V
	    ------------------------- user/kernel boundary
				  |
				  |
				  |
				  V
			    ALSA sequencer
          
	    (sticks instr. request in FIFO, calls wakeup())
		  
		 ---- 1 OR MORE CONTEXT SWITCHES ---
				   
				  |
				  |
				  |
				  V
	   -------------------------- user/kernel boundary
				  |
				  |
				  V
			user-level instrument manager
				  |
				  |
				  |
				  V
	   -------------------------- user/kernel boundary
				  |
				  |
				  V
			    ALSA sequencer
			    
		  (calls function in device driver)
				  |
				  |
				  |
				  V
			(data routed to card)
				  |
				  |
				  V
		 ---- 1 OR MORE CONTEXT SWITCHES ---
				   
				  |
				  |
				  |
				  V
	   -------------------------- user/kernel boundary
				  |
				  |
				  |
				  V

		(back to original user level application)

I hope I got this right.

This scheme seems, well, a little crazy to me.

Because I'm not interested in music playback (other than via
/dev/dsp), I can't even imagine using a program that corresponds to
the "user level application that wants to load an instrument". The
kinds of software I use (and write) are really like the instrument
manager, except that they don't claim to be generic - they are tools
that provide a manipulative interface to a synthesizer that otherwise
has no accessible controls (i.e. a soundcard synth, or even an
external synth with a microwave-like interface such as the Matrix-6 I
own).

I have always been a fan on using user-level libraries to accomplish
the kind of things that the proposed instrument manager would do
here. Its faster, more debuggable and ultimately more flexible. I
don't understand why an application should have to call into the
kernel and then wait for some other process to take care of its
request when it could just have called a library routine to take care
of the same thing:

	       user-level application wants instrument
				  |
				  |
				  |
				  V
		       (calls library function)
				  |
				  |
				  |
				  V
	   -------------------------- user/kernel boundary
				  |
				  |
				  V
			    ALSA sequencer
			    
		  (calls function in device driver)
				  |
				  |
				  |
				  V
			(data routed to card)
				  |
				  |
				  V
			(return from syscall)
				  |
				  |
				  V
	   -------------------------- user/kernel boundary
				  |
				  |
				  V			
			 original application
				  


So that would be my preferred architecture. Such a scheme gets rid of
the intermediate "instrument manager", which I think is a pretty wierd
notion anyway (for my purposes). I continue to sense that Jaroslav's
notion of an "instrument" is not sufficiently well-defined, and so I
worry that the "instrument manager" will end up being a nasty mess of
soundcard-specific code.

However, I do note that the scheme has the benefit of effectively
making the original application "multithreaded", since the actual
instrument loading is carried out by the instrument manager, while the
original requestor can continue doing other things (assuming the
control flow in the sequencer is done sensibly for such "slow" requests).

In the meantime, though, this whole model of instrument "search lists"
seems to me to be something that absolutely does not belong in the
device driver, and arguably not in anything except a soundcard-aware
user application. What you're essentially trying to do is to cache the
state of the soundcard synth on the host side, and my experience with
such attempts for other kinds of hardware indicates that this is
nearly always a mistake. 

But again, I have very little interest in music playback software, and
most of the discussion so far has focused on these kinds of
applications.

--regards,
--p


