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 reason. "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. So what? 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 Thing. 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 anyway. > 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 many cases). In other places, that's not the case. Point being this is the host author's - not the plugin specification's - business. -DR- _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev