28 Jun
2005
28 Jun
'05
8:31 p.m.
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).
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/