RealTime Library

The RealTime Library provides a convenient, higher-level interface to underlying hardware timers that is easy to use. The library also provides for the distribution of timing pulses to an unlimited number of client applications on a priority basis, thus supporting multitasking in the most robust manner possible.

Conductors and Players

The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).

Each Conductor can have one or more client applications. A second structure called a Player is set up by each client application that wants to get timing information from the Conductor. There is typically one Player for each task that wants to get timing information (a task could have more than one but this would be unusual).

Both the Conductor and Player structures are dynamic. You never create these structures by allocating and initializing them yourself. The system provides the functions to do this for you. Also, the structures are read-only. To change the fields within these structures, use the system-provided functions and tags.

An application will usually create a single Player structure and then attach it to a Conductor. If the Conductor does not yet exist, it will be created by the system. To create a Player structure you call CreatePlayer():

struct Player *player = IRealTime->CreatePlayer(Tag tag, ...);

This call takes a list of tag items that describe the attributes of the Player structure you want to create. (A complete list of all the tags available can be found in the Autodoc for the SetPlayerAttrs() function.) It returns a pointer to the Player structure. Here’s a fragment showing how to set up a Player:

struct Player *player = IRealTime->CreatePlayer(
  PLAYER_Name, "My_player",
  PLAYER_Conductor, "My_conductor",
  TAG_END);

if (player != NULL )
{
  // Your real-time application goes here...

  IRealTime->DeletePlayer(player);
}

In the code above, a Player will be created with the name of "My_player". It will be attached to the Conductor structure named "My_conductor". If a Conductor structure named "My_conductor" does not already exist, the system will create one. Other applications could also attach their Players to "My_conductor".

When your application finishes, you should delete any Players you have created by calling DeletePlayer(). The Conductor will be automatically deleted by the system (however, this won’t happen until all the Players attached to a Conductor are deleted).

Once you have a Player and Conductor set up, you can obtain timing pulses for your application. Timing pulses come from underlying timer chips and are passed to your application through the Conductor.

Getting Clock Ticks

The RealTime Library uses a tick frequency of 1200 Hz, so clock pulses are delivered approximately every 0.83 ms. This is good enough even for timing-critical applications such as MIDI sequencing.

There are two ways to get this timing information:

• An alarm's signal
• A clock tick callback hook

Using the alarm facility

You can ask the RealTime Library to signal your task at some future time by using its alarm facility. This allows you to operate asynchronously. For instance, you could start a group of MIDI notes playing and set the realtime alarm to signal you when they should be stopped, then go on to some other job such as preparing the next group of notes before calling Wait() on the alarm signal.

The fragment below shows how to set up the library’s alarm clock to signal the calling task at time = 1000 ticks (the fragment assumes that the RealTime Library interface is already obtained).

// This fragment assumes the that IRealTime is already obtained.
int8 midiSignal = IExec->AllocSignal(-1);  // Allocate a wake-up signal bit
if (midiSignal != -1)
{
  struct Player *player = IRealTime->CreatePlayer(
    PLAYER_Name, "My_player",
    PLAYER_Conductor, "My_conductor",
    PLAYER_AlarmSigTask, IExec->FindTask(NULL),
    PLAYER_AlarmSigBit, midiSignal,
    TAG_END);

  if (player != NULL)
  {
    // Start the realtime clock running.
    int32 res = IRealTime->SetConductorState(player, CONDSTATE_RUNNING, 0);
    if (!res)
    {
      BOOL timerr = IRealTime->SetPlayerAttrs(player,
           PLAYER_AlarmTime, 1000,
           PLAYER_Ready, TRUE,
           TAG_END);
      if (timerr)
      {
        // You could do some other job before
        // calling Wait() on the alarm signal.
        IExec->Wait(1UL << midiSignal);
      }
      else IDOS->Print("Couldn't set alarm\n");
    }
    else IDOS->Printf("Couldn't start clock\n");
  }
  else IDOS->Printf("Couldn't set up Player structure.\n");
}
else IDOS->Printf("Couldn't allocate signal.\n");

In the fragment above, the calling task requests a Player with an alarm clock feature by passing the PLAYER_AlarmSigBit tag to CreatePlayer() The ti_Data field of this tag contains the signal bit that will be set by the RealTime Library when the alarm goes off. The PLAYER_AlarmSigTask tag indicates which task will be signaled.

The realtime clock is then started by calling SetConductorState(); see below. This is important since any alarm requests made when the clock is stopped will be ignored.

Finally, the alarm time is set by calling SetPlayerAttrs(). The parameters to this call are:

BOOL result = SetPlayerAttrs(struct Player *player, Tag tag, ...);

The player parameter indicates which Player structure is to have its attributes changed. The Tag items indicate the attributes and their new values. If the change is made successfully, then TRUE is returned. FALSE indicates failure. In the fragment above, a wake-up time is requested using the PLAYER_AlarmTime tag. Also, the calling task indicates to the Conductor that it is ready by using the PLAYER_Ready tag (more on this below).

At this point, the call to Wait(1UL << midiSignal) causes the task to sleep until time = 1000 ticks.

Using the clock tick callback facility

The discussion so far has concentrated on the alarm facility of the RealTime Library. An even finer level of control over time is available using the clock tick callback hook facility. Instead of setting an alarm to signal your task at some future time, the hook facilities allow your application code to be invoked whenever Conductor time is updated.

The realtime clock is driven by an interrupt that simply increments the base time and then uses software interrupts to distribute the time to any Conductors. By using a callback hook, you can have your custom code invoked at the software interrupt level (before tasks) whenever Conductor time is refreshed.

To set up a callback hook, you use the PLAYER_Hook tag with the address of a standard Hook structure as defined in <utilities/hook.h>. This structure contains the address of the code you want to be invoked whenever the RealTime Library updates your Conductor. Here’s a code fragment showing how this is done:

struct Task *My_task;
int8 My_signal;

uint32 My_hookFunc(struct Hook *hook, struct pmTime *msg, struct Player *pl);

int main()
{
  // ...Open the RealTime Library and do other set up here...

  struct Hook My_hook;
  My_hook.h_Entry = (HOOKFUNC)My_hookFunc;
  
  uint32 ticks = 1000;
  stuct Player *player = IRealTime->CreatePlayer(
        PLAYER_Name, "My_player",
        PLAYER_Conductor, "My_conductor",
        PLAYER_Hook, &My_hook,
        PLAYER_UserData, &ticks,
        TAG_END);
    
  if (player != NULL)
  {
    My_task   = IExec->FindTask(NULL);  // Initialize these globals so that
    My_signal = IExec->AllocSignal(-1); // the hook function can signal us.
    if (My_signal != -1)
    {
      // Start the clock running.
      int32 res = IRealTime->SetConductorState(player, CONDSTATE_RUNNING, 0);
      if (!res)
      {
        // ...your code goes here...
        IExec->Wait(1UL << My_signal | SIGBREAKF_CTRL_C);
      }
      
      IExec->FreeSignal(My_signal);
    }
    
    IRealTime->DeletePlayer(player);
  }

  // ...Close the library, etc...
}

In the code above the function named My_hookFunc() will be called by the RealTime Library whenever it updates Conductor time.

Here’s the callback hook function itself. This simply compares Conductor time to a variable, ticks, whose address is pointed to by pl->pl_UserData. Notice how this address was filled in using the PLAYER_UserData tag in the call to SetPlayerAttrs() in main() above. When Conductor time equals or exceeds ticks, the hook function signals the main task.

// Hook code called whenever the RealTime Library updates Conductor time.
// Normally this is 1200 times/sec.
uint32 My_hookFunc(struct Hook *hook, struct pmTime *msg, struct Player *pl)
{
  switch (msg->pmt_Method)
  {
   case PM_TICK:
     // Test whether Conductor time has exceeded the number in *ticks*.
     // If it has, then signal the parent task.
     if ((*uint32*)(pl->pl_Userdata)) < pl->pl_Source->cdt_ClockTime)
       IExec->Signal(My_task, 1UL << My_signal);
     break;

   default:
     break;     
  }
  
  return 0;
}

More About Conductors

It is the job of the Conductor to act as middleman between the Amiga's timing hardware and client tasks represented by Player structures. Each Conductor keeps track of:

• an Exec list of all its client players
• the state of the conductor (i.e. running, stopped, paused, locating – see below)
• what time it is relative to start time
• whether the Conductor is using the Amiga’s internal hardware for its timing pulses or an external source

As shown in the examples above, the "state" of the Conductor can be changed at any time by calling SetConductorState(). If the call succeeds, zero is returned:

int32 res = IRealTime->SetConductorState(struct Player *player, int32 newstate, int32 ti);

The player parameter is a pointer to a Player structure that is linked to the Conductor you want to change. The ti parameter is a time offset used for special cases (typically set to zero). The newstate parameter is one of the following:

CONDSTATE_STOPPED	The clock is not running
CONDSTATE_PAUSED	To the RealTime Library, this is exactly the same as stopped. This is provided as a convenience to those applications that wish to make a distinction between the two.
CONDSTATE_RUNNING	The clock is running and time pulses are being distributed to any client applications (Players) that are ready.
CONDSTATE_LOCATE	This is the same as running with one exception: the clock does not actually start until all client applications have indicated that they are ready by setting the PLAYER_Ready attribute of their Player to TRUE. This allows applications that cannot start immediately to set up before timing pulses actually begin.

The difference between locating and running requires some explanation. Each Player has a "ready bit" which is used to tell the RealTime Library that the player is ready to receive ticks. This bit is reset each time the library relocates the clock to a new time.

The reason for the ready bit is that some applications need to find the appropriate location in the multimedia sequence or score before they can start playing at the new location. In some cases this can take a considerable amount of time. Hence, CONDSTATE_LOCATE is used with the ready bit to allow all players that are sharing a timing context to be synchronized together.

Players can set the state of their ready bit by using the PLAYER_Ready tag attribute either when the Player is created with CreatePlayer() or later with SetPlayerAttrs(). See the first code fragment above for an example of this.