Re: [LAD] FLTK vs GTKmm

From: Jens M Andreasen <jens.andreasen@email-addr-hidden>
Date: Tue Aug 11 2009 - 14:54:39 EEST

Continuing this increasingly inaccurately christened thread ..

On Tue, 2009-08-11 at 11:26 +0100, Steve Harris wrote:

> It's not ideal, but assembling all the jack buffers into one big one
> is not going to be that much load on the CPU.
>

OK .. Adrian Knoth showed some interest and says he knows his way around
in jackd as well as a colleague involved with CUDA. If the idea after
evaluation does not appear to be worth the effort, then we'll just drop
it by then.

> Another tack would be to provide a library that could execute LV2
> plugins (with CUDA versions of the code in the bundle). It would
> presumably need a daemon or such, but would be more generally useful
> than a hacked jackd.
>

That would have to be a collection of generally useful plugins, at least
32 channels wide to be worth it. A mega plugin so to say. This ain't no
lawn-mover you can turn around on a platter. Doing little things here
and there /only/ would be very difficult in general.

The thing to notice is that, although several kernels can be launched
the one after the other, at any given time there is only one running
which will have to be aware of which codepath to take depending on what
processor it is running on. Or else you'll end up with 640 identical
channel-strips rather than something like a synth-collection, 64 fully
equipped channel-strips + a few reverb units as well as an autocomposer
based on neural networks (Well OK, that last one might be a bit over the
top... :)

As long as you only have a single 8 core multiprocessor, the GPU can be
utilized fully by a single somewhat demanding project. It is when there
are dozens of cores to feed that the need for cooperation arises, and
this is as far as I can see where things are heading, also over in
Intel/Larrabee land.

> The whole point of
> jack is that it lets you combine bits of software in different ways,
> this would take that away to some extent.
>

 To some extent, yes. But provided that the host isn't spending much
time on moving buffers around, you'll still have all of your (much more
flexible) CPU left to use for additional processing. Having this much
processing power available in a way also eliminates /the need/ for
carefully selecting what channels should be processed by what plugin.
Just do everything for all, possibly with all settings turned down to
zero or bypassed on some, even most channels.

Some effects will still be optional - like say time stretching, which
might not be a natural choice for the basic bread-and-butter setup, no
matter how much icing you put on it. Or maybe it is? Some people will
most likely disagree with me here ..

To put things in some economical perspective, I am talking about
upgrading this tiny desktop-machine to having bandwidth and processing
power twice that of a current top-of-the-line Intel Nehalem for less
than $200, maybe around Christmas. Inexpensive (!Apple) laptops with
GPU's like that are hitting the channel as we speak.

/jma

> - Steve

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Aug 11 16:15:03 2009

This archive was generated by hypermail 2.1.8 : Tue Aug 11 2009 - 16:15:03 EEST