[gst-devel] Re: Fwd: Re: [linux-audio-dev] MAIA status

[David Olofson]

On Wednesday 17 January 2001 07:27, Erik Walthinsen wrote:
> On Wed, 17 Jan 2001, David Olofson wrote:
> > I've not studied GStreamer thorougly yet, but I've browsed their
> > web site and looked at some code. On the plugin and inner DSP
> > loop level, it basically has the same problems as VST 1.0 and
> > LADSPA; it can't efficiently deal with sample accurate events,
> > and from what I've seen, it doesn't even have the concept of
> > sub-buffer resolution.
>
> First of all, I'm not very familiar with most pro-audio stuff, I'm
> learning as fast as I can, but I'm focusing on live audio for the
> most part.  But in order for GStreamer to not suck at some things,
> it seems I need to dig into this stuff a bit more.
>
> Can you explain what you mean by the phrases 'sample accurate
> events' and 'sub-buffer resolution'?

This is basically two terms related to the same thing; the ability to 
tell a plugin to do something at a specific and accurate time (or 
position in the buffer, if you prefer), rather than right away, 
affecting the first sample of the next buffer passed to the 
process()/run()/whatever() call.

You need this for accurate control of fast transients in plugin 
parameters, and for accurate timing of state changes.


>  I have a feeling the former
> is not within the scope of gstreamer, and the latter concept can be
> mapped onto bits of GStreamer, but is also not quite within the
> scope.  I.e. both problems are left up to higher layers of code
> which are not yet written (but are planned).

This is how some other APIs solve this issue, but it has an inherent 
problem: As the lower level (the raw inner DSP loop) has no concept 
of sample accurate timing built into the API, it has to be encoded by 
the implementations of the higher level interfaces, and then decoded 
and interpretted by the DSP loop.

MAIA - as opposed to VST 2.0, which has a similar event system, which 
is strapped onto an older, function call based API - implements 
sample accurate timing from the ground up; every plugin has an outer 
event decoding loop around the DSP loop (*), and breaks the inner 
loop to process every event before the exact sample as indicated by 
the event timestamp. This is normally done entirely within the outer 
loop of the plugin - no function calls; just raw, optimized inline 
code.

(*) Except for plugins that really don't want or can't respond with
    sample accuracy - for those, you just process all events for
    the current buffer before entering the DSP loop. That's all -
    no special cases at run time, host support or anything.


> (BTW, I have a wrapper for LADSPA plugins in there, it just doesn't
> work quite yet: higher priorities prevail).

That's nice! :-)

Integration and connectivity of all kinds is exactly what we need to 
get Linux audio to a seriously usable level. No single person, or 
even project, can possibly create The Music And Audio Application 
that will satisfy all needs, so we need to make sure the bits and 
pieces from various projects can be used together to solve real 
problems.


//David

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david at linuxdj.com -'