29 Jun
2005
29 Jun
'05
7:48 a.m.
On Wed, Jun 29, 2005 at 12:31:49AM +0200, Florian Schmidt wrote:
On Tue, 28 Jun 2005 21:38:32 +0100
Chris Cannam <cannam(a)all-day-breakfast.com> wrote:
...
It does seem a shame not to end up with a DSSI
plugin as well, then,
given that it would then have much the same structure already.
Yeah, you definetly are right. I wonder though:
Why stop at garanteeing a fixed buffer size for the whole runtime. The
thing with the partitioned convolution is that, when used purely as an
effect for recorded material (i.e. not playing realtime through it, in
a host that can compensate for plugin delay), then large buffers
definetly are desirable. Even larger than i.e. the maximum period size
of my soundcard (which is 2048 frames). Plus i wonder whether the (then fixed) buffer size
should be user
configurable in any way or would the plugin simply report "16k frames is
what i want" :) Sometimes it does make sense to use it in realtime mode
(with the same buffer size as the audio system), if you have the cpu
power or the responses are short enough.
I dont think youre going to get host developers to buy this, its basically
moving the same problem you have into thier space. There are most hosts
than plugins that do partitioned convolution, so the best thing to do is
hack it up in the plugin. IMNSHO.
NB There is allready a LADSPA plugin that does partitioned convolution
(imp, id:1199), it just doesnt guaranteee that it will have constant cpu
load, and burst proceswses when its buffers are full. This is a reasonable
approach and not hard to implement. If the plugin /hints/ ontop of this
that running it with power of two sized buffers of at least 1024 frames
(or whatever) is a good idea then the sitatuion is less painful for host
developers, as they can safely ignore it.
In practice you will find that most hosts dont divide up the buffers they
get from JACK/ALSA, so choking slightly when you get non power of two
buffers is not that big a gamble.
- Steve