[linux-audio-user] Re: [DSSI] [ANN] dssi-convolve-0.0.3
mista.tapas at gmx.net
Mon Nov 28 13:51:10 EST 2005
On Mon, 28 Nov 2005 04:57:56 +0100
Florian Schmidt <mista.tapas at gmx.net> wrote:
> this is the third release of dssi-convolve. This time it has a GUI and
> might even work ;)
This plugin will probably not work in "freewheeling" modes, i.e. for an
ardour mixdown (if ardour supported DSSI ;)). It relies on regular
timing for its process calls because the real work is offloaded to
another thread. To fix this, a host would have to have an ability to
tell the plugin, that it doesn't run realtime anymore. in this case, the
plugin working scheme would have to be changed to run in a single thread
for the nonrealtime operation. This would be possible. But afaik DSSI
doesn't have a provision for this.
zero-additional-delay mode (as jack_convolve does) is also not (yet)
possible with dssi_convolve as the host has no way to tell the plugin
its buffer size. If it had this ability, there would be a way to add
zero-additional-delay mode to dssi_convolve which would basically work
the same as jack_convolve's (simply using a partitionsize equal to the
host's buffersize) with the (only technically interesting) exception
that it would still need an internal buffer to collect samples for the
whole buffer as DSSI plugins' buffer sizes can be chopped into chunks by
the host (as LADSPA allows), which is necessary for automation purposes
(changing control data on non bufferboundaries. This is will have a
slight performance drawback, but not in delay terms.
Ah, there would be another guarantee needed besides the host telling the
plugin its buffersize:
the host will call the plugin with max. buffersized process chunks plus
it will have to chop chunks at least at buffer boundaries, too (i.e.
process chunks may cross over a buffersize boundary).
I wonder how this could best be implemented in DSSI w/o breaking the
More information about the linux-audio-user