[Ardour-Users] GUI toolkit support

[Adriano Petrosillo]

On Fri, 16 Nov 2018 16:36:55 -0500
Paul Davis <paul at linuxaudiosystems.com> wrote:

> On Fri, Nov 16, 2018 at 4:31 PM jonetsu <jonetsu at teksavvy.com> wrote:
> 
> > On Fri, 16 Nov 2018 20:29:59 +0100
> > Robin Gareus <robin at gareus.org> wrote:
> >
> > > On 11/16/2018 08:22 PM, jonetsu wrote:
> > >> At the moment each plugin is a distinct linvst process, which
> > >> prevents them from communicating between each other (very minor
> > >> drawback).
> >
> > > Try that with 64 tracks, 2-3 plugins (Compressor, EQ) per track and
> > > the cost of context switches will become obvious.  It's far from
> > > minor, even on modern CPUs.
> >
> > Fortunately, in the Ardour/Mixbus(32C) family the compressors and EQs
> > per track are already built-in.
> >
> 
> Absolutely not true of Ardour.
> 
> So that leaves the processing power for other, specialized, plugins.
> > Maybe a special compressor is needed.  Or a special EQ.  Or of course,
> > effects of all kinds.
> >
> > And also, if 64 tracks with 2-3 plugins is what constitutes a
> > processing challenge, then that leaves a lot of room for other uses.
> > So far at the creation stage, which is done in Bitwig (all mixing is
> > done in Mixbus32C) I've ran perhaps 35 tracks with maybe 20 of then
> > being soft synths (both Linux native and linvst) and others being audio
> > tracks with some having plugins (also both Linux and linvst).  All of
> > them running in the default config of what Bitwig calls 'independent
> > plug-in host process for each plugin'.  On a i5 3.2GHz with 16G RAM.
> >
> 
> You're not really understanding the challenge.
> 
> The context switching between the plugin "host" and the actual DAW takes
> time. Actual time. Not very much time, but actual time.
> 
> Multiply this up across many plugins in many tracks, and it starts to be an
> appreciable fraction of the entire time available to process a buffer's
> worth of audio.
> 
> Now, if your DSP load without the out-of-process plugins was very low, then
> the out-of-process aspect won't push it up into territory where you have
> problems (though the chance of this increases as the buffer size goes
> down). But the out-of-process part is "stealing" time from the available
> processing part. Your system may be fast enough to deal with it - that's
> great. But the "theft" is real whether it causes you problems or not, and
> it points to the fundamental problem with this design. It's not hard to
> come up with scenarios where even though there are zero problems, your CPU
> is spending more time context switching than actually processing audio. And
> for what? To workaround buggy code?
> 
> For movie post-production, 64 tracks is the bottom end of the track count
> scale. 200 might be common.

Just for sake of argument, the number of tracks may be irrelevant. Post-processing does not usually need short buffers, the buffers may as well be as large as they can be (within reason), even 100ms delay for instance is not a big deal and it is quite a lot of time to work with even with hundreds of tracks.

Plus, the idea is that only problematic plugins are run independently in a separate process, so unless you deliberately use plugins that need to be run like that, or it can end up being a negligible cost.

-- 
Adriano Petrosillo <ampetrosillo at gmail.com>