From: David O. <da...@ga...> - 2001-01-17 07:15:37
|
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=20 tell a plugin to do something at a specific and accurate time (or=20 position in the buffer, if you prefer), rather than right away,=20 affecting the first sample of the next buffer passed to the=20 process()/run()/whatever() call. You need this for accurate control of fast transients in plugin=20 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=20 problem: As the lower level (the raw inner DSP loop) has no concept=20 of sample accurate timing built into the API, it has to be encoded by=20 the implementations of the higher level interfaces, and then decoded=20 and interpretted by the DSP loop. MAIA - as opposed to VST 2.0, which has a similar event system, which=20 is strapped onto an older, function call based API - implements=20 sample accurate timing from the ground up; every plugin has an outer=20 event decoding loop around the DSP loop (*), and breaks the inner=20 loop to process every event before the exact sample as indicated by=20 the event timestamp. This is normally done entirely within the outer=20 loop of the plugin - no function calls; just raw, optimized inline=20 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=20 get Linux audio to a seriously usable level. No single person, or=20 even project, can possibly create The Music And Audio Application=20 that will satisfy all needs, so we need to make sure the bits and=20 pieces from various projects can be used together to solve real=20 problems. //David =2E- M A I A -------------------------------------------------. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `----------------------> http://www.linuxaudiodev.com/maia -' =2E- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--------------------------------------> da...@li... -' |