Re: [linux-audio-dev] Draft: Audiality article for MusicStation

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke loka   06 1999 - 22:13:38 EDT


>If/when I can grasp what David's event system is all about,
>I can start commenting on the design. ;) I guess a concrete
>use-case example would help.

I'll try to give my understanding. Consider a two thread system, one
of them is basically doing a tight select(2) loop on an fd
representing a MIDI interface, and the other is the DSP engine thread.

--------------------------------------------------------------------

Thread 1:
=========

while (1) {
      select (N, &fds, ...)
      if (readable (midi_fd)) {
             get_sample_accurate_timestamp ();
             read_midi_data ();
             event_list = parse_midi_data ();
             engine->inject_events ();
      }
}

Thread 2:
=========

while (1) {

      get_new_events ();
      foreach active plugin {
           build_plugin_event_list ();
           plugin->process (...., event_list, ...);
      }

}

---------------------------------------------------------------------

You can also thread 1 or an additional thread running a GUI, and
sending events about UI-driven changes to the engine.

Key components of the system are:

    get_sample_accurate_timestamp () - this gets the number of the
                                       the sample currently believed to
                                       be playing on the DSP's
                                       output(s).

    engine->inject_events () - allows another thread to add
                                       events to those waiting to be
                                       processed by the DSP engine thread.
                                       
    build_plugin_event_list () - takes events from the pending
                                       event list in the DSP engine thread,
                                       and puts them in a data
                                       structure that is passed to the
                                       plugin.
 
Notice the need for mutexes within engine->inject_events(), at the
very least.

I hope this helps, if only to clarify my own understanding of David's
proposal.

Here is the current "competing" idea (quite possibly a serious logic
flaw here, but you'll get the idea):

Thread 2:
=========

while (1) {

      pending_events = get_new_events ();
      foreach active plugin {
           foreach pending_event {
                   compute_frames_till_event ();
                   plugin->process (...., frames );
                   plugin->notify (pending_event);
                   compute_frames_till_next_event ();
                   plugin->process (...., remaining_frames);
      }
}

--p
 
                                       


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST