[LAD] "enhanced event port" LV2 extension proposal
drobilla at connect.carleton.ca
Fri Nov 30 00:38:57 UTC 2007
On Thu, 2007-11-29 at 01:49 +0100, David Olofson wrote:
> On Thursday 29 November 2007, Dave Robillard wrote:
> > Well, sure, but big data is big data. In the typical case plugin
> > buffers are much smaller than the cache
> Of course, but that's exactly what I'm talking about - large buffers,
> and why it doesn't make sense to support them. :-)
It makes a lot less sense to explicitly deny them for no particular
"You can't use events larger than x bytes"
Why? Because some Dave or another said it could possibly be slow in
certain cases? Sure, there's a performance hit running on really
massive buffers. There's a performance hit running on tiny buffers too.
There are times when running on single sample buffers is what you want
to do, even though it's slow. There are other times when running on
massive buffers is what you want to do, even though it's slow. If you
don't want to do that, well... don't do that. Currently the only limit
on sizes of things in LV2 is the range of uint32_t, and this is a Good
Not explicitly making things verboten != "supporting"
I do agree we should not be adding crufty features to support massive
buffers, if that's what you mean. It's easier to just split the cycle
> Last time I looked into this, a reasonably optimized resampler with
> cubic interpolation and some ramped parameters was memory bound even
> on a lowly P-III CPU, at least with integer processing. (Haven't
> actually tested this on my AMD64...)
> I think floating point should be as fast or faster in most cases, at
> least on P-III CPUs and better - and with SIMD, you may get another
> 2x-4x higher throughput at that.
A clever host can just use the same, say, 2 buffers (stereo audio), so
running a bunch of plugins on it will be in the cache the entire time.
Ardour, for example, (usually) runs the entire route's chain of plugins
on the same buffers in-place. For any reasonable Jack buffer size on
any reasonable modern CPU, those buffers are going to be in the cache
for the duration of that entire chain's processing. For non-in-place
chains, add a factor of 2 (and it's still going to all fit in cache in
In other places, that's not the case. Point being this is the host
author's - not the plugin specification's - business.
More information about the Linux-audio-dev