[gmpi] Re: Generalized Music Plugin Interface list is now online

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 19:59:45 +0100

On Tuesday 11 February 2003 16.30, Martijn Sipkema wrote:
> [...]
> > That's an interesting idea. In XAP we have this "worker
> > callback"=3D20 feature planned for loading files, allocating
> > buffers and other stuff=3D20 that would otherwise screw the RT
> > audio thread.
> >
> > However, there's a problem with doing this on your average PC=3D20
> > operating system: Scheduling latency. You can get away with
> > having=3D20 one thread per CPU doing RT stuff (with some luck, good
> > drivers and=3D20 lots of tuning), but if you start relying on lower
> > priority threads=3D20 meeting deadlines, you're asking for trouble,
> > unless you're on a=3D20 proper RTOS. (Well, it means trouble even
> > then - it's very hard to=3D20 design multithreaded hard RT systems
> > of this kind - but at least you=3D20 can expect the OS to schedule
> > the right thread at the right time.)
> Well, if asynchronous processing is needed, as is the case for FFT,

It's not strictly required for FFT, and in fact, I'd advice against=20
doing it that way.

Just give the FFT call a "context struct", and a way of telling it how=20
much of the transform to do in each call. Then use this to dispatch=20
the work evenly over process() calls. This gives you even and well=20
defined CPU load, and avoids the headache and potential performance=20
issue that is multithreaded programming.

> then you'll need an operating system that provides decent rt
> scheduling.

Yes, but that solves only *part* of the problem. A network of=20
interdependent hard real time threads and global deadines to meet is=20
a very hard thing to get right. An RTOS makes it at least=20
theoretically *possible*, but it cannot magically make any program=20
deterministic, if it isn't deterministic by design.

> The asynchronous processing should run at a lower
> priority than the normal processing, depending on its deadline.

It's not as simple as that; very far from it.

> For
> this to be portable and for different plugins to cooperate the
> plugin should request asynchronous processing from the host.

Sure, and I think that's a very useful feature to have (if not=20
*required* for some plugins to run in a real time host at all) -=20
although *not* for hard real time work.

Just think about what happens if you have a bunch of plugins doing=20
this at the same time. You'd need an EDF scheduler. (Earliest=20
Deadline First; a type of RT scheduler that considers each thread's=20
next deadline, as well as how much CPU time it will need to finish.)=20
To use one, you have to tell the host how many cycles each "worker=20
thread" needs to finishing, and when the next deadline for each=20
thread is.

Get the picture?

You'll never find anything like an EDF on a general purpose OS, I=20
think. In fact, most RTOSes don't have one either, since it's just=20
too hard to get right and too hard to use. There are patches for=20
RTLinux and/or RTAI, if you *really* need to do this kind of work,=20
but let's just say, pretty much any other solution that will get the=20
job done will be both simpler and more robust. EDF is handy for some=20
soft real time things, but professional real time audio is *not* soft=20
real time.

//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

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: