Subject: Re: Fwd: Re: [linux-audio-dev] MAIA status
From: David Olofson (david_AT_gardena.net)
Date: Wed Jan 17 2001 - 09:17:03 EET
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 -'
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 09:47:00 EET