Re: [linux-audio-dev] rough rough ladspa docs

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

Subject: Re: [linux-audio-dev] rough rough ladspa docs
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Mon May 15 2000 - 01:17:57 EEST


On Sun, 14 May 2000, Paul Barton-Davis wrote:
> >For example, I am going to propose a semantical
> >change for LADSPA_PROPERTY_HARD_RT_CAPABLE
> >soon. The amended comment is merely:
> >
> > The plugin will not block on I/O.
>
> This is insufficient. If the plugin blocks on a mutex, then its not
> HARD_RT_CAPABLE. I would go for something like:
>
> The plugin will never block (pause computation to wait for
> disk i/o, a signal, a mutex, or anything else).
>
> --p

-- 

I am not sure if I am missing something, but from my ladspa.h I read the following: (see end of mail) (in short use plain C/C++, you are allowed to call the math library, and if you are very careful you can even use syscalls if you know that you will not block for undetermined time)

Perhaps a LADSPA_PROPERTY_RUN_WITHIN_IRQ/KERNEL_CAPABLE would be handy indicating that besides that you are hard RT capable, you assure that you don't make ANY syscalls, except code which is allowed to be called from an IRQ/kernel)

/* Property LADSPA_PROPERTY_HARD_RT_CAPABLE indicates that the plugin is capable of running not only in a conventional host but also in a `hard real-time' environment. To qualify for this the plugin must satisfy all of the following:

(1) The plugin must not use malloc(), free() or other heap memory management within its run() or run_adding() functions. All new memory used in run() must be managed via the stack. These restrictions only apply to the run() function.

(2) The plugin will not attempt to make use of any library functions with the exceptions of functions in the ANSI standard C and C maths libraries, which the host is expected to provide.

(3) The plugin will not access files, devices, pipes, sockets, IPC or any other mechanism that might result in process or thread blocking.

(4) The plugin will take an amount of time to execute a run() or run_adding() call approximately of form (A+B*SampleCount) where A and B depend on the machine and host in use. This amount of time may not depend on input signals or plugin state. The host is left the responsibility to perform timings to estimate upper bounds for A and B. */

*/

Benno.


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

This archive was generated by hypermail 2b28 : Mon May 15 2000 - 00:46:44 EEST