From alsa-devel-owner@alsa.jcu.cz  Fri Oct 30 20:18:03 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 UAA16442;
	Fri, 30 Oct 1998 20:17:34 +0100
Date: Fri, 30 Oct 1998 20:17:34 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Paul Barton-Davis <pbd@op.net>
cc: alsa-devel@jcu.cz
Subject: Re: ALSA sequencer and synth control (Was Re: ALSA + AWE32) 
In-Reply-To: <199810301430.JAA26496@renoir.op.net>
Message-ID: <Pine.LNX.3.96.981030195743.30707C-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 Fri, 30 Oct 1998, Paul Barton-Davis wrote:

> 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.

Yes, this is right...

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

Explain is bellow...

> 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.

Maybe I didn't write about this instrument downloading before, but I'm
thinking that ALSA sequencer must be able to do both methods:

  - application requests some MIDI sample, this application doesn't
    know anything about instrument downloading, it is written for
    standard MIDI interface, thus downloading of MIDI instruments must
    be handled in sequencer in two ways: preload complete instrument set
    or load on demand
  - application knowns about instrument interface and uses it for
    instrument requests (good for MOD players and MIDI players and
    for all situations where instruments should be downloaded before
    playing - including live playback)
 
> 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. 

No, please, we can do effective caching of instruments if possible. In
driver MUST be some kind of list of instruments to handle MIDI program
change and other instrument change requests...

> 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.

As I say before, sequencer interface should support both things:

  - download instrument on demand
  - download instrument within playback application before it will be used

There is only discussion how can be 'download instrument on demand'
interface done... I prefer use sequencer for this, no next interface...
We must also solve possible collisions between 'load on demand' and
'load before'...

						Jaroslav

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


