From alsa-devel-owner@alsa.jcu.cz  Mon May 11 23:32:10 1998
Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id XAA06407
	for <alsa-devel@jcu.cz>; Mon, 11 May 1998 23:31:57 +0200
Received: from obelix.fvdpol.inter.nl.net by altrade.nijmegen.inter.nl.net
	via bd99-17.Breda.NL.net [193.79.246.242] with ESMTP for <alsa-devel@jcu.cz>
	id XAA05264 (8.8.8/3.27); Mon, 11 May 1998 23:31:54 +0200 (MET DST)
Received: (from frank@localhost) by obelix.fvdpol.inter.nl.net (8.8.7/8.7.3) id WAA24436 for alsa-devel@jcu.cz; Mon, 11 May 1998 22:59:47 +0200
From: Frank van de Pol <F.K.W.van.de.Pol@inter.nl.net>
Message-Id: <199805112059.WAA24436@obelix.fvdpol.inter.nl.net>
Subject: New Sequencer core: Timing
To: alsa-devel@jcu.cz (alsa)
Date: Mon, 11 May 1998 22:59:46 +0200 (MET DST)
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


Thanks guys for all the response I got on my proposal. It appears that there
are some mixed ideas about the timing / timestamping of events. Perhaps this
will help (or not...).


Each sequencer system has one 'clock' and one 'queue'. 

- this 'clock' is just a time-keeper for current time and tick, depending on
  the acutal tempo and the time/tick of last tempo change, and acts as the
  master clock for this sequencer system.
- This clock is advanced by a hardware timer, wich could be the system clock
  (running at 10ms) or some other clock source.
- Current tick position is derived from the real-time.
- The master clock can send sync data to clients capable of processing this
  sync data (eg. sending out SMPTE or MTC)
- The master clock can be set to receive timing information, and synchronise
  to that time source.

If one needs to have multiple independed tempo's playing, he or she will
need to run 2 or more independed sequencer systems (which could all be run
by the same sequencer core).


The sequencer's clients submit events to the queue. This queue is internaly
setup as two priority queues: one for real-time timestamps, and one for
song/tick timestamps, but that is not visible from outside. The client can
specify either the real-time or the song/tick timestamp to an event
depending on it's need. (For songs, this will typically be the song/tick
timestamp, for events that are tied to real-time like audio and video
playback it will be real-time stamps.

If only one of these two types would be supported, it will always be a
tradeoff...



Location of the Sequencer Core
==============================

This whole sequencer core will reside in kernel space, to make use of the
ability to run directly from interrupt code and call (kernel) clients
directly from interrupt more. That way we can assure the lowest latency (eg.
on forwarding MIDI data from one port to another).



Synchronisation
===============

To allow synchronisation of the clock to external sources this clock can be
adjusted (in gradual steps?) to a value that we want it to have (make it run
faster/slower until we are in sync). Timing source I can think of:
- Internal clock (no external sync)
- MTC
- SMPTE
- FSK
- Wave playback/recording

Like the clock can be adjusted by the real-time time sources, we can also
adjust tempo to sync to:
- MIDI clock/songposition
- other 'metronome', click track


As the 'clock' can both send and receive timing information, the possibility
to synchronise multiple computers is still open. <dream-mode> This way we
can even build whole clusters of music producing Linux computers. :-)
</dream-mode>


Regards,
Frank.

========================---------------->
#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

