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). So it would be cool, if the plugin could use a fixed buffer size which also differs from the buffer size used by the underlying audio system (i.e. jack). For this the host would have to do some extra work (setup an extra thread to process the plugin (with a slightly smaller priority than the jack audio callback thread for example, to even the load), ringbuffers to feed/consume data to/from it), latency compensation for tracks sent through it. Or should the plugin do this internally and simply report to the host that it needs a fixed buffer size (which then corresponds to the audio system's buffer size).. Are dssi/ladspa's allowed to do threading? Without i wouldn't know how to do it. And even if it were allowed to do threading, how would the dssi know which priorities to use, etc (on a RP kernel it should have prio higher than i.e. hd and net irq's, but lower than the jack audio thread). 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. Regards, Flo -- Palimm Palimm! http://affenbande.org/~tapas/
