From alsa-devel-owner@alsa.jcu.cz  Wed Apr 29 10:40:09 1998
Received: from pat.bath.ac.uk (qmailr@pat.bath.ac.uk [138.38.32.2])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id KAA30698
	for <alsa-devel@jcu.cz>; Wed, 29 Apr 1998 10:40:05 +0200
Received: (qmail 28756 invoked from network); 29 Apr 1998 08:40:02 -0000
Received: from solomon.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.1)
  by pat.bath.ac.uk with SMTP; 29 Apr 1998 08:40:02 -0000
Received: from tobi.bath.ac.uk by solomon.bath.ac.uk id aa05946;
          29 Apr 98 9:40 BST
Message-ID: <3546E73A.493F@bath.ac.uk>
Date: Wed, 29 Apr 1998 09:39:22 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: New Sequencer core (long...)
References: <199804272059.WAA32321@obelix.fvdpol.inter.nl.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hello,

 Some comments.

Frank van de Pol wrote:

> Ascii graphic of architecture:
> 
>   =========================
>   ||                     ||
>   ||                    \||/                 \
>   ||  +--------+      +--\/------------+      |
>   ||  |        |      |                |      |
>   ||  | Timing | -->- | Priority Queue |      |
>   ||  |        |      |                |      |
>   ||  +--------+      +--------||------+      |
>   ||                           ||             \ Sequencer
>   ||                          \||/            /   Core
>   ||  +--------+  +------------\/--------+    |
>   ||  | Client |  |                      |    |
>   /\  | Manager|  |     Event Router     |    |
>  /||\ |        |  |                      |    |
>   ||  +--------+  +---||-----------||----+    |
>   ||                 \||/         \||/        /
>   ||               +--\/--+     +--\/--+
>   ||               |Client|     |Client|
>   ||               |  1   | ... |  n   |
>   ||               +--||--+     +--||--+
>   ||                  ||           ||
>   ||                 \||/         \||/
>   ||                  \/           \/
>   ===================================
> 
> 
> All events flow through the queue. Because a priority queue is used instead
> of a simple FIFO, it's no problem to accept events from multiple clients.
> (At long as the queue is not full anyway, a well behaved application should
> send only as much events that are needed to achieve tight playback (eg. 1
> second), and not to try keep the queue overflowing.)
> 
> Clients can either be user-land applications, accessing /dev/seq or kernel
> modules that can directly submit events, and are directly called when a
> event it dispatched to them (even from interrupt mode).
> 
> To change internal parameters of the sequencer like eg. tempo &
> synchronisation a special client will (always) be present within the system.
> If an application wants to have a tempo change it then simply can send a
> TEMPO event into the system.

 I think we may need several schedulers to allow different clients to
vary
their tempos independently. 

- 2 users may want to use the system. I do not want my tempo to be
changed by another. 

- Another situation is the mixing of tempo and real time events. A
sequencer may be
playing a midi tune using the tempo but special effects applied to an
individual
note may require to be scheduled 80ms after the note on event.



> Event Structure
> ---------------
> 
> All the events have (apart) from their specific content a few common fields
>         - timestamp (in midi ticks), like oss /dev/music
>         - message type/id (eg. NOTE_ON, CHANGE_TEMPO,...)
>         - destination, to which client(s) is the message to be send. An
>           event can be send to either:
>            a) a specific client, in this case the client number has to
>               be given.
>            b) all clients that have registered for this (class of) event
>               this is basicly a broadcast.
>           This destination also can have (for eg. note events) a port and
>           channel.

 Maybe a handle for who sent the event might be required ?

> Events a modeled after MIDI, but are not restricted to be MIDI events. Any
> event that one can think of can be fed into the sequencer and dispatched at
> the specified time to the specified device(s).

 MIDI events suck. MIDI should be a wrapper layer for those who have
existing applications.
However, the design of good generic interface for the different devices
is still quite tricky.
If I have written a piece of music for my AWE32 using some of it's cool
filter sweeps 
how will a GUS card play this ? One solution is to have adaptors e.g.
AWE32->GUS but this
explodes as the number of devices increases. A generic device would need
to know about main features
of all cards. Then we can have AWE32->generic   generic->GUS
The raw Awe32 will provide the neatest possible interface to all the
features of the AWE32.
If you are not concerned about portibility you can use this direct. If
you are concerned
about portility you should use the generic interface and an adaptor ?


> ------------------------------------------------
> 
> For some (historical?) reason OSS provides two different sequencer
> interfaces, /dev/sequencer (the old one), and /dev/sequencer2, also known
> as /dev/music. Is there a good reason why a new sequencer core also should
> provide 2 interfaces? What's exactly the difference between these
> interfaces. For backwards compatiblity I understand why these two should be
> implemented, but is there any reason why the functionalty cannot be provided
> by one (good) sequencer?


 _I think_ /dev/music adds some voice/patch management for the OPL3 and
GUS cards. Whem
I asked I was was told that there was no point using /dev/music for the
AWE32 interface.
The AWE32 driver does it's own voice management. [ within the device the
AWE32 there are 30
sample players when the user wants to play a note something needs to be
clever enough to allocate
these sample players for the job ]  The /dev/sequencer GUS interface
required the user to do this.

> If the only real issue is that the old interface gives lower-level access to
> a synth device, and such can't be achieved by a simple interface wrapper
> (eg. access to every single voice in the GUS for playing MOD files), it
> could be an idea to provide such synths with a CAP_LOWLEVEL_SYNTH, or
> CAP_LOWLEVEL_AWE32 capability flag. (And perhaps a message to switch from
> one mode to another.
> 
> Idea: If one wants to have access to individual voices, these can also be
> addressed as a buch of midi channels (eg. 0..31), with each channel
> representing a singe voices.

 With the AWE32 the voices are done in software, each time a note is
played
the pointers to the sample in memory and all the synth parameters are
loaded into the device.
I do not know how the GUS works.

> 
> Synchronisation
> ---------------
> 
> One of the points the currently available sequencer solution lacks is
> synchronisation. Synchronisation can be used in a few places:
> 
> - Normal master clock is the system timer (typically 10ms).
> - To get higher resolution, any timer within the system can be used. Most
>   soundcards have a timer onboard that is capable of generating interrupts.
>   This can be used as master clock for the sequencer.
> - Audio playback can also act as a timesource for synchronisation. By using
>   a counter of the number of samples played for syncing the master clock,
>   it's a good starting point to get MIDI in sync with digital audio.
> - MIDI clock can also be used as time source for the sequencer. Or one can
>   decide to use MTC. These two protocols can be received and used to adjust
>   the internal clock, or even simpler can be transmitted.
> - Some cards have a special synchronisation port (SMPTE code, FSK or
>   something similar). This port can also play it's role in the
>   synchronisation game.
> 
> ========================---------------->
> #define NAME    "Frank van de Pol"
> #define ADDRESS "mgr. Nelislaan 10"
> #define CITY    "4741 AB Hoeven"
> #define COUNTRY "The Netherlands"
> #define EMAIL   "F.K.W.van.de.Pol@inter.NL.net     -o)
>                                                    /\\
> Linux - Why use Windows, since there is a door?   _\_v
> ------
> To unsubscribe from <alsa-devel@alsa.jcu.cz> mailing list send message
> 'unsubscribe' in the body of message to <alsa-devel-request@alsa.jcu.cz>.

-- 
 Cheers Paul.                                        
               __         __                  
              (  ) _ - _ (  )                 
               ~~         ~~                  
                (  0   0  )                   
----------ooO----(       )----Ooo------------ 
          '''     (     )     '''             
                   (   )                      
                    \ /                       
                   ~~O~~                      

  Tel: +44 1225 826108
  Fax: +44 1225 826305
snail: P.J.Leonard
       Applied Electromagnetic Research Centre
       Bath University,
       BATH, UK   BA2 7AY

