On Wed, Jun 29, 2005 at 12:31:49AM +0200, Florian Schmidt wrote: > On Tue, 28 Jun 2005 21:38:32 +0100 > Chris Cannam <[EMAIL PROTECTED]> 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
