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

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 16:15:10 +0100

On Tuesday 11 February 2003 15.10, Vincent Burel wrote:
> firstly i propose to make a processing classification.
>
> A - the strict inplace plug-in.
> ----------------------------
> these processing take "n" samples and return "n" samples. whatever
> "n" =3D 0 to infinite. This kind of plug-in can manage several input
> and several output in real time, and are easy to port on DSP system
> where the latency time is often fixed (e.g. 32 samples , 64
> samples).

Your average Rt plugin, that is. :-)


> B - the non real time plug-in.
> ----------------------------
> These kind of plug-ins are needing a minimum of sample number
> before processing. They cannot be implemented on a real time system
> without modifying some part of it. For example processing needing
> FFT 1024 sample, needs 1024 samples to start to process something.
> But on a low latency stream, you may be  called every 32 samples ,
> so if you process 1024 sample on a single call, you kill the
> stream. In this case , or the programmer is able to diffuse the
> processing in small part (e.g. 32 samples) or the system is able to
> provide an other kind of delayed call to avoid DSP overload....
> (that we call in the hardware domain the double interrupt call, a
> first interrupt push/pull samples, the second on is called when the
> required number of sample is riched).

That's an interesting idea. In XAP we have this "worker callback"=20
feature planned for loading files, allocating buffers and other stuff=20
that would otherwise screw the RT audio thread.

However, there's a problem with doing this on your average PC=20
operating system: Scheduling latency. You can get away with having=20
one thread per CPU doing RT stuff (with some luck, good drivers and=20
lots of tuning), but if you start relying on lower priority threads=20
meeting deadlines, you're asking for trouble, unless you're on a=20
proper RTOS. (Well, it means trouble even then - it's very hard to=20
design multithreaded hard RT systems of this kind - but at least you=20
can expect the OS to schedule the right thread at the right time.)


> C - Conversion Plug-in.
> ----------------------------
> These kind of product can process "n" samples and return "m"
> samples. "n" !=3D "m". This is the case for time stretching , or
> variospeed processing, or simply an audiot format conversion
> processing.

I think this is beyond the scope of RT plugins, and therefore possibly=20
beyond the scope of GMPI. I can't really speak for the latter,=20
though.

The problem is that you can't really do this in real time, unless you=20
have multiple "asynchronous" processing nets.


> Secondly i will recommand to this community to talk first about
> differents problems met here and there , in order to get the best
> overview as possible of the GMPI challenge.

Yes, I think that's the main idea with this discussion.


//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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: