[gmpi] Re: Topic 5: Threading

  • From: Bill Gardner <billg@xxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 28 Apr 2003 15:43:45 -0400

Here's a stab at summarizing the threading topic. Feel free to comment/dissent/modify - Bill


1. What kind of realtime guarantees are there, i.e., how do we handle
plugins that run at > 100% of realtime?

No strategy was developed to guarantee glitch-free operation in the case of the plug-in graph taking too long to generate output. It is up to the host implementation to detect and respond to the graph consuming too much CPU. Professional DAW hosts may stop the graph and mute audio. A streaming media player host may decide to forge ahead, possibly bypassing CPU-hungry plugs. GMPI may provide means for hosts to notify plug-ins (or for plug-ins to query hosts) about CPU consumption.

2. Does the host provide some kind of threading environment?

Initially divided into two strategies:

1.) Host is in charge of all thread synchronization. No plugin functions are re-entrant or asynchronous.
2.) Plugin is in charge of synchronization, based on API defined rules. Some calls may be re-entrant, some may not.

Strategy 1 was refined. Only one DSP function is called at a time from the host, though the functions may be called from different host threads. This means the host is the arbiter of all access to the DSP object from other objects. So the GUI object, for example, must communicate with the DSP object via the host. This implies an architecture where the host queues all asynchronous events for the DSP object, and sends them to the DSP object from the processing thread prior to calling the plug's process method. The DSP object must process all events in a timely manner, deferring time-consuming tasks such as sample bank loading to a low priority thread which can be polled for completion. Presumably the host would provide an interface to create and synchronize such helper threads.

Advantages of strategy 1 are primarily that the plug-in developer need not deal with thread synchronization in the DSP object (ease of development), and it is a clean, unambiguous design. A possible disadvantage is difficulty in implementing plug-in adapters while maintaining the constraints. Strategy 1 seemed to be generally accepted.


At 11:08 AM 4/28/03 -0400, you wrote: 
I'm back, trying to dig out from being away for a week.  If you want to
summarize the threading topic, I'll post the next one from the agenda.

-----Original Message-----
From: Bill Gardner [mailto:billg@xxxxxxxxxxxx]
Sent: Monday, April 28, 2003 11:00 AM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: using another plugin API


Good point, I'm putting the cart in front of the horse. I agree with you
that we should continue the official agenda at a quickened pace. If Ron has
no objection (Ron are you there?), I'd be willing to summarize the current
topic (threading) and propose the next, hopefully by tomorrow.

Bill

At 10:32 PM 4/25/03 -0400, you wrote:
> >The advantage of using another API such as AU as a starting point is that
> >it greatly expedites the design process. Even if we don't have rights to
> >use the code, it's nice to be able to say "we should implement the ABC
> >functionality the way that XXX API does it".
>
>yes, of course. but look: the reason we are following the current
>design process is so that we can be clear about what we *want*. not
>what an API looks like but what it can do. apple had some good people
>work on CoreAudio and AU, but it didn't have all of us. we can get a
>much better picture of the full requirements than they or any other
>individual company/organization can do.
>
>once we know that, it might be easy to say "lets just
>hijack/use/copy/extend XXXXX" (where XXXXX could be AU, for
>example). we have to get there before we can move forward to talk
>about what the API might actually be, and i would echo my earlier
>point that we simply continue moving forward with this discussion, at
>a faster pace if possible.
>
> >the best parts of existing APIs. The problem is that a lot of the
> >particular knowledge comes to us under non-disclosure agreements, so in
>
>we are designing an API, not an implementation. as i understand it, i
>could reimplement a CoreAudio or AudioUnit library tomorrow by
>downloading the API docs from apple, and there is nothing they could
>do to stop me. i wouldn't try it though. starting so many variable
>names with "k" just makes me feel seasick :)
>
>i note that i haven't signed any NDAs or anything like them wrt any
>plugin API, and yet i already have a fairly detailed knowledge of how
>several of them work. TDM is a closed book, but from reading between
>the lines of many different sources, i think i have a pretty good
>idea. Rewire is similar.
>
>--p
>
>----------------------------------------------------------------------
>Generalized Music Plugin Interface (GMPI) public discussion list
>Participation in this list is contingent upon your abiding by the
>following rules:  Please stay on topic.  You are responsible for your own
>words.  Please respect your fellow subscribers.  Please do not
>redistribute anyone else's words without their permission.
>
>Archive: //www.freelists.org/archives/gmpi
>Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

----------------------
Bill Gardner
Wave Arts, Inc.
99 Mass. Ave., Arlington, MA 02474
Tel: 781-646-3794   Fax: 781-646-7190
billg@xxxxxxxxxxxx


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe


----------------------
Bill Gardner
Wave Arts, Inc.
99 Mass. Ave., Arlington, MA 02474
Tel: 781-646-3794   Fax: 781-646-7190
billg@xxxxxxxxxxxx


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 04-2003