The situation of a single plug that consumes > 100% of realtime is just one
example of a graph that is under-running the output, i.e., failing to fill
the output buffer in time. You can always load up a graph with small plugs
until it underruns. How to handle this should be up to the implementation
of the host. A DAW host would likely detect the underrun, stop the graph
and display an error, but the host could also try to prune the graph to
catch up, or do something else. Because the plug in a shared address space,
the plug already has to "play nice", so I wouldn't expect the host to
provide any mechanism for recovering gracefully from a process method that
takes too long, i.e., if the plug does a while (1) in its process method,
the resulting behavior is host dependent.
With that said, I'd like to hear ideas about what kind of services a host
could provide to deal with this.
I don't think realtime DSP environments are very different. There might be
an interrupt procedure that is filling/emptying the I/O buffers, and the
main thread is doing the processing. If the main thread takes too long, you
get underruns and nasty clicks. I wouldn't expect things to crash though.
Bill
At 11:24 AM 4/10/03 -0400, you wrote:
>>> >1. What kind of realtime guarantees are there, i.e., how do we handle >plugins that run at > 100% of realtime?
ron, can you clarify what you mean by this? <<<
I'm still drying tears from eyes after that last thread, but I'll try. ;-)
Assume a GMPI plugin will be cross compiled to either a general purpose O/S like Windows or a hard-realtime O/S. In the former, a plugin will run in as timely a fashion as the scheduler will permit, and if the plugin uses more than its quantum it'll get preempted and audio will "glitch" or "gap."
I'm not too familiar with the hard realtime world, but isn't it true that on these kinds of systems a DSP module must have known and bounded CPU overhead? If you exceed your quantum on such a system, don't you essentially take the whole system down with you?
So I was imagining we'd need to define a mechanism to manage CPU overhead of plugins to suit different host environments.
---------------------------------------------------------------------- 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
