SEQUENCER


1.4 Timing and Synchronization

1.4.1 Time format

Sequencers for musical application have to cope with two different notations of time:

  1. real/clock-time, expressed in seconds (or fractions of it of course, eg. ms or us.
  2. song-position, expressed in clock ticks, which are related to the tempo the song is playing.
Because of the specific character of music (ie. it has tempo, groove etc.) the second one is preferred. For synchronization to real-time sources like for instance audio or video the first one is preferred. Conversion between these two types is trivial once the currently active tempo and timestamp (in both units!) of last tempo change is known.

A problem arises when we have events queued (using either time format) and have to change tempo or adjust time (for synchronization). To determine dispatch time and order of events we need to be able to compare time stamps of events. If there is a constant tempo, that can easily be done. But when a tempo is changed, the number of clock ticks (ppq) per second changes, and events in the queue will not have correct ordering anymore. To avoid this problem, the queue will implemented as two parallel priority queues: one song queue and one real-time queue.

The existence of these two queues will be hidden for the client applications. The clients will only be presented one queue that can be fed with two type of time stamps

1.4.2 Synchronization

One of the shortcomings of the currently available sequencer solution is synchronization. The sequencer can be the timing master and be used to synchronize other sequencers, or it can be a timing slave and thus has to synchronize to another time source. These two types are completely different and can even be used concurrently.

1.4.3 Synchronizing sequencer to external timing source

The sequencer can be used as slave to synchronize to another master.

In cast the sequencer has to sync to another source, it will keep using it's own local timer for determining schedule time of events. This local timer (not the central hardware timer) or the tempo will be adjusted to match the time master.

1.4.4 Sequencer as timing master

1.4.5 Synchronization events

The event transport mechanism is used for synchronization. Clients can send and receive synchronization events. Synchronization events can (just like normal events) be send to a specific client or broadcasted to all clients that registered for getting synchronization events.

The timer of the sequencer can be seen as an internal client. In situations where multiple timing sources exist (eg. MTC and audio) the client has to select from which source to handle the synchronization events.

A client can act as a synchronization master (transmitter) or synchronization slave (receiver), even at the same time!



Version 0.036, April 2nd, 1999Usage:
Copyright (c) 1998 by Frank van de Pol, NetherlandsAdvanced Linux Sound Architecture