20 Oct
2012
20 Oct
'12
6:14 a.m.
convoLV2 is an LV2 plugin to convolve audio signals without additional
latency.
https://github.com/x42/convoLV2
https://github.com/x42/convoLV2/tarball/v0.2
convoLV2 is in an early stage of development and is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as an instantiate option
* Block length must always be a power of 2 (a required feature)
See the links in the README and on the github page for details about
these features. The first should be trivial to implement in any host,
which is highly recommended. The second may be difficult or impossible,
though it is trivial in hosts that run plugins directly on the Jack
cycle[1] or process files with fixed parameters.
This plugin is intended to provide latency-free synchronous convolution,
which inherently requires these restrictions. It does not, and will not
ever, do latent audio buffering in the plugin itself (though a generic
wrapper to do so is a good idea...)
This release is known to work in Jalv 1.2.0. If you're feeling
adventurous and remove the power of 2 feature requirement from the data,
it will also work in Ardour3. Sometimes. Maybe.
convoLV2 is jointly developed by Robin Gareus (who wrote the entire
plugin before LV2 could properly support it) and David Robillard (who
invented/implemented the missing LV2 pieces).
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
This announcement is exclusive to developer mailing lists. Feel free to
reply with any thoughts, and report back with any host implementation
progress so the README can be updated.
Happy Hacking,
-dr
[1] Assuming the Jack block length is a power of 2 anyway, which is not
actually guaranteed, but is true in any case sane enough to care about.
20 Oct
20 Oct
9:54 a.m.
Am 20.10.2012 06:14, schrieb David Robillard:
convoLV2 is an LV2 plugin to convolve audio signals
without additional
latency.
https://github.com/x42/convoLV2
https://github.com/x42/convoLV2/tarball/v0.2
convoLV2 is in an early stage of development and is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as an instantiate option
* Block length must always be a power of 2 (a required feature)
See the links in the README and on the github page for details about
these features. The first should be trivial to implement in any host,
which is highly recommended. The second may be difficult or impossible,
though it is trivial in hosts that run plugins directly on the Jack
cycle[1] or process files with fixed parameters.
This plugin is intended to provide latency-free synchronous convolution,
which inherently requires these restrictions. It does not, and will not
ever, do latent audio buffering in the plugin itself (though a generic
wrapper to do so is a good idea...)
This release is known to work in Jalv 1.2.0. If you're feeling
adventurous and remove the power of 2 feature requirement from the data,
it will also work in Ardour3. Sometimes. Maybe.
convoLV2 is jointly developed by Robin Gareus (who wrote the entire
plugin before LV2 could properly support it) and David Robillard (who
invented/implemented the missing LV2 pieces).
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
Could you provide a bit more info about why and how IR.lv2 violate the
LV2 specifications,
and (for a non-native english speaker) what is mean by "kludges"?
greats
hermann
This announcement is exclusive to developer mailing lists. Feel free to
reply with any thoughts, and report back with any host implementation
progress so the README can be updated.
Happy Hacking,
-dr
[1] Assuming the Jack block length is a power of 2 anyway, which is not
actually guaranteed, but is true in any case sane enough to care about.
21 Oct
21 Oct
1:47 a.m.
On Sat, 2012-10-20 at 09:54 +0200, hermann meyer wrote:
Am 20.10.2012 06:14, schrieb David Robillard:
Mainly two things, both mentioned on its page:
State is saved by abusing control ports to encode a hash which is used
to look up data saved in a special location on the file system unknown
by the host.
One version's control ports may not actually be changed except at
specific times (described as not being "automatable" in Ardour). The
other is latent to avoid this (not a spec violation, but a non-latent
plugin would of course be nice).
It also requires the custom GUI to work, and that GUI violates host-UI
separation so it does not work in hosts with a split there. This is not
a violation either, but it's certainly not good.
convoLV2 is an LV2 plugin to convolve audio
signals without additional
latency.
https://github.com/x42/convoLV2
https://github.com/x42/convoLV2/tarball/v0.2
convoLV2 is in an early stage of development and is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as an instantiate option
* Block length must always be a power of 2 (a required feature)
See the links in the README and on the github page for details about
these features. The first should be trivial to implement in any host,
which is highly recommended. The second may be difficult or impossible,
though it is trivial in hosts that run plugins directly on the Jack
cycle[1] or process files with fixed parameters.
This plugin is intended to provide latency-free synchronous convolution,
which inherently requires these restrictions. It does not, and will not
ever, do latent audio buffering in the plugin itself (though a generic
wrapper to do so is a good idea...)
This release is known to work in Jalv 1.2.0. If you're feeling
adventurous and remove the power of 2 feature requirement from the data,
it will also work in Ardour3. Sometimes. Maybe.
convoLV2 is jointly developed by Robin Gareus (who wrote the entire
plugin before LV2 could properly support it) and David Robillard (who
invented/implemented the missing LV2 pieces).
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
Could you provide a bit more info about why and how IR.lv2 violate the
LV2 specifications, and (for a non-native english speaker) what is mean by
"kludges"?
It means an ugly workaround.
-dr
20 Oct
20 Oct
1:44 p.m.
On Sat, Oct 20, 2012 at 12:14:29AM -0400, David Robillard wrote:
convoLV2 is in an early stage of development and is
not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as an instantiate option
* Block length must always be a power of 2 (a required feature)
See the links in the README and on the github page for details about
these features. The first should be trivial to implement in any host,
which is highly recommended. The second may be difficult or impossible,
though it is trivial in hosts that run plugins directly on the Jack
cycle[1] or process files with fixed parameters.
Since you invited remarks:
ConvoLV2 uses libzita-convolver, but in a very inefficient way,
by restricting it to a single partition size equal to the process
block size. This is NOT necessary in order to obtain zero latency,
in fact the whole point of zita-convolver is that it can provide
zero latency even if most of the convolution is computed using
partition sizes much larger than the process block size.
This plugin is intended to provide latency-free
synchronous convolution,
which inherently requires these restrictions.
This is simply not true. A fixed, power-of-2 block size is NOT
necessary in order to obtain zero latency, not even if you use
multiple partition sizes. Supporting an arbitrary block size
(within some reasonable limits) is just a bit more complicated.
But it can be done quite efficienty using two Convproc instances
for example.
Thirdly, for the use case of reverbs, the whole latency issue is
just irrelevant. A reverb IR should not contain the direct sound
(since this will be mixed in separately), and in fact the first
10 ms or so should be silence anyway, they don't contribute to
the effect and just cause coloration. Which means you can adopt
a scheme that permits arbitrary block sizes by allowing one (Jack)
period of latency. Just remove as many samples from the start of
the IR to compensate.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
7:43 p.m.
On 10/20/2012 01:44 PM, Fons Adriaensen wrote:
[..]
The plugin uses a single non-threaded libzita-convolver Convproc
instance which imposes those restrictions.
ConvoLV2 uses libzita-convolver, but in a very
inefficient way,
Yes, we are aware of that. At this point in time we favor clean design
over efficiency. The choice to use a fixed blocksize comes from the fact
that we do not want libzita-convolver to spawn addtional threads nor
makes use the semaphores in libzita's process callback.
This plugin is
intended to provide latency-free synchronous convolution,
which inherently requires these restrictions.
This is simply not true. Thirdly, for the use case of reverbs, the whole
latency issue is
just irrelevant.
quite so. But not all convolution is reverb.
The real issue we have is small block-sizes in general.
Effect processing in cycles smaller than 64 ffp are not too unusual. The
current block-size limitation in Convproc does not allow an even
distribution of the CPU load across process cycles. Nor does using
background threads and thread sync methods in the process callback. This
becomes particular important for very small cycles. The current sync
mechanism in libzita convolver can not guarantee to process N samples in
time. There are small subtleties WRT to synchronization in particular
because the LV2 process callback can be used in both realtime and
offline rendering mode, which may change without prior notice.
Currently these shortcoming are a feature. We wanted a LV2 plugin that
demonstrates new LV2 features - in particular a plugin that demos
instantiation options. One of those being frames-per-process cycle
limitations that the plugin can impose.
For a later, user-centric release, we're planning to use the hybrid
direct FIR + FFT (libzita) approach that you suggested and things will
change. We very much appreciate your feedback. Should you become bored
on one of those upcoming Italian winter nights, we'd very much
appreciate some insight regarding a lockless, threadless implementation
possibility.
ciao,
robin
11:03 p.m.
On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus wrote:
On 10/20/2012 01:44 PM, Fons Adriaensen wrote:
What's the problem with the semas ? They are the simplest and most
efficient way to signal an event. And unless you use the 'sync' mode
(which you should do only when Jack is freewheeling), they are used
only to trigger the lower priority threads, and the thread calling
Convproc->process() will never wait for a sema or be blocked.
And what's the problem with the threads ? The only one I see is that
LV2 doesn't have any way to pass the required priority parameter, but
there are simple ways around that.
ConvoLV2 uses libzita-convolver, but in a very
inefficient way,
Yes, we are aware of that. At this point in time we favor clean design
over efficiency. The choice to use a fixed blocksize comes from the fact
that we do not want libzita-convolver to spawn addtional threads nor
makes use the semaphores in libzita's process callback. The real issue we have is small block-sizes in
general.
Effect processing in cycles smaller than 64 ffp are not too unusual. The
current block-size limitation in Convproc does not allow an even
distribution of the CPU load across process cycles.
CPU load per cycle will be strictly constant if the minimum partition
size is equal to or greater than the period. This was a design requirement.
When you use a period size smaller than 64 frames you have to buffer
up to 64 frames, and indeed in that case you will call Convproc->process()
in some cycles and not in others. But if you use multiple partition sizes
then only a small fraction of the work is done synchronuously, so even if
the load is not strictly constant, the variation will be small compared
to the total load.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
21 Oct
21 Oct
1:02 a.m.
On Sat, 2012-10-20 at 21:03 +0000, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus
wrote:
The goal of the plugin is to do synchronous (i.e. processing in the
run() context) convolution in a *strictly* hard-real-time fashion with
no latency. Doing the processing in another thread(s) does not meet
this requirement essentially by definition. Yes, it can work well
enough, sometimes, but that is different.
If the processing is happening in another thread, then e.g. at the very
first block, run() must either:
(1) Wait (i.e. block) for the other thread to process the data
(2) Add latency
(3) Busy wait and drop out if data is not available "in time"
(4) Attempt to split the work such that when run() finishes its part
the others will be done
(4) is admittedly clever, if you know there's idle cores to make it
beneficial and make some optimistic assumptions about scheduling.
convoLV2 aims to not do any of these things by doing the processing
synchronously, which is much simpler and more reliable. The cost is
block length restrictions.
Plugins that launch a bunch of processing threads can be problematic for
other reasons, e.g. if you have many of them instantiated, and they are
already spread across all available cores by the host (as Ardour can).
No amount of priority tweaking will make hundreds of threads thrashing
in a situation like this work well, it's bloated and will fall apart
much sooner than synchronous plugins. Other issues include memory
consumption, complexity and non-portability in plugins, priority
configuration as you mentioned, etc.
Using threads can be a perfectly reasonable thing to do, but the goal
and requirements of this plugin are as stated, which means no threads.
It breaks down pretty simply into two cases:
(1) Block length is arbitrary, in which case threads are necessary
(2) Block length restrictions can be guaranteed, in which case threads
are pointless bloat
convoLV2 aims to be the best solution for (2), at the cost of not being
a solution for (1) whatsoever. Threads may work for (2), but are not
ideal (especially when the host is already multi-threaded).
I don't claim synchronous is ideal for all, or even most situations, but
it definitely is for some.
-dr
On 10/20/2012 01:44 PM, Fons Adriaensen wrote:
What's the problem with the semas ? They are the simplest and most
efficient way to signal an event. And unless you use the 'sync' mode
(which you should do only when Jack is freewheeling), they are used
only to trigger the lower priority threads, and the thread calling
Convproc->process() will never wait for a sema or be blocked.
And what's the problem with the threads ? The only one I see is that
LV2 doesn't have any way to pass the required priority parameter, but
there are simple ways around that. ConvoLV2 uses libzita-convolver, but in a very
inefficient way,
Yes, we are aware of that. At this point in time we favor clean design
over efficiency. The choice to use a fixed blocksize comes from the fact
that we do not want libzita-convolver to spawn addtional threads nor
makes use the semaphores in libzita's process callback.
1:38 p.m.
On Sat, Oct 20, 2012 at 07:02:16PM -0400, David Robillard wrote:
The goal of the plugin is to do synchronous (i.e.
processing in the
run() context) convolution in a *strictly* hard-real-time fashion with
no latency. Doing the processing in another thread(s) does not meet
this requirement essentially by definition.
This is again *simply not true*. It's actually possible to prove that
the scheme used by zita-convolver will not fail unless the synchronous
solution would fail as well. This goes back to research done in the
1980's, you'll find the proof somewhere in the IEEE transactions on
parallel processing of around that time.
One reason (particular to this application and not even required for
the proof), is that using multiple partition sizes reduces the work
to be done, not just per CPU, but the total amount. Let's take one
example, the 'greathall' reverb that comes with jconvolver. Let's
assume a Jack period of 256 frames.
If done entirely synchronously, it uses 440 partitions of 256 frames.
When using multiple partition sizes, zita-convolver will (in this case)
use 3 partitions of 256 frames, 6 of 512 frames, 6 of 2048 frames, and
13 of 8192 frames, for a total of 28 partitions.
It's easy to show that to a first approximation the total CPU load
for FFT based convolution is proportional to the number of partitions
(exercise for the reader).
That means that the second solution takes 28/440 or around 7% of the
CPU load required for the first. Even if we allow for some overhead,
let's say it will be 15% instead of 7%, it's rather clear that in a
highly loaded system the synchronous solution will fail to deliver in
real time *way before* the other one. And what's worse, it will take
the rest of the Jack graph with it. In the other case, if the system
is fully loaded, the lower priority threads will fail, but your Jack
graph will still work.
If the processing is happening in another thread, then
e.g. at the very
first block, run() must either:
(1) Wait (i.e. block) for the other thread to process the data
(2) Add latency
(3) Busy wait and drop out if data is not available "in time"
(4) Attempt to split the work such that when run() finishes its part
the others will be done
Zita-convolver does none of (1), (2), or (3). Unless in sync mode, but
then it isn't supposed to work in real time.
(4) is admittedly clever, if you know there's idle
cores to make it
beneficial and make some optimistic assumptions about scheduling.
It does not depend on idle cores, it works perfectly on a single CPU
system as well.
Going back to the example above, the thread that does the 512 frames
partition is supposed to run every 512 frames of course. But its output
is not required until 768 frames (3 * 256) later. So it can be up to
a full Jack period late without any ill consequences. Does your approach
allow that ? For the lower priority threads there's even more headroom,
for example the last one runs every 8192 frames but its output is
required only after 16128 frames. So it can be 31 periods late without
affecting the output.
Note that the per-thread 'late' status flags provided by Convproc just
indicate that a thread had not finished its previous period when a new
one was to start. This does *not* mean that the thread is actually too
late delivering its contribution. Even in the worst case it still has
one Jack period of time, and for most of the threaads, a lot more.
convoLV2 aims to not do any of these things by doing
the processing
synchronously, which is much simpler and more reliable.
As shown above, in real life it will be much *less* reliable.
The cost is block length restrictions.
Again, that is not true. You can continue to repeat this, but that
will still not make it true.
Plugins that launch a bunch of processing threads can
be problematic for
other reasons, e.g. if you have many of them instantiated, and they are
already spread across all available cores by the host (as Ardour can).
No amount of priority tweaking will make hundreds of threads thrashing
in a situation like this work well, it's bloated and will fall apart
much sooner than synchronous plugins.
No, the opposite is true.
Other issues include memory consumption,
Nonsense. The bulk of memory used by a convolution algo is taken by signal
data in various forms. The multi-partition solution does not require any
more. And the overhead for the thread objects etc. is absolutely trivial
compared to what's required anyway for a typical reverb.
complexity
Ever taken a look at the FFTW code (which you use anyway) ? It's order
of magnitude more complicated than zita-convolver. Complexity is not
an issue.
and non-portability.
Zita-convolver works on Linux and OSX, that does not depend on *how*
you use it.
(1) Block length is arbitrary, in which case threads
are necessary
(2) Block length restrictions can be guaranteed, in which case threads
are pointless bloat
Both (1) and (2) are simply untrue, there is *no* relation at all between
using threads and allowable block sizes. You are really showing that you
haven't even started to understand how partitioned convolution works.
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
2:04 p.m.
Am 21.10.2012 13:38, schrieb Fons Adriaensen:
Zita-convolver works on Linux and OSX, that does not
depend on*how*
you use it.
And on FreeBSD as well, if you add this little patch to allow it. ;-)
ähm, this one.
http://patch-tracker.debian.org/patch/series/view/guitarix/0.22.4-1/01-fix-…
2:15 p.m.
On Sun, Oct 21, 2012 at 02:04:45PM +0200, hermann meyer wrote:
Am 21.10.2012 13:38, schrieb Fons Adriaensen:
???
The current source already has
_____
#if defined(__linux__) || defined(__FreeBSD_kernel__) || defined(__GNU__)
// NOTE: __FreeBSD_kernel__ and __GNU__ were added by the Debian maintainers
// (the latter for the HURD version of Debian). Things are reported to work
// with some applications but probably have not been tested in depth.
#include <semaphore.h>
_____
The reasons for the comments are that having <semaphore.h> does not
imply that a complete implementation is available. For example, on
OSX some functions are provided but empty, which is why there is
special code for that case.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Zita-convolver works on Linux and OSX, that does
not depend on*how*
you use it.
And on FreeBSD as well, if you add this little patch to allow it. ;-)
http://patch-tracker.debian.org/patch/series/view/guitarix/0.22.4-1/01-fix-…
5:35 p.m.
On Sun, Oct 21, 2012 at 11:38:26AM +0000, Fons Adriaensen wrote:
And upon re-reading (4), zita-convolver doesn't do that either.
So it does 'none of the above'.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
If the
processing is happening in another thread, then e.g. at the very
first block, run() must either:
(1) Wait (i.e. block) for the other thread to process the data
(2) Add latency
(3) Busy wait and drop out if data is not available "in time"
(4) Attempt to split the work such that when run() finishes its part
the others will be done
Zita-convolver does none of (1), (2), or (3). Unless in sync mode, but
then it isn't supposed to work in real time.
7:36 p.m.
On Sun, 2012-10-21 at 11:38 +0000, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 07:02:16PM -0400, David
Robillard wrote:
The goal of the plugin is to do synchronous (i.e.
processing in the
run() context) convolution in a *strictly* hard-real-time fashion with
no latency. Doing the processing in another thread(s) does not meet
this requirement essentially by definition.
This is again *simply not true*. It's actually possible to prove that
the scheme used by zita-convolver will not fail unless the synchronous
solution would fail as well. This goes back to research done in the
1980's, you'll find the proof somewhere in the IEEE transactions on
parallel processing of around that time.
[etcetcetcetcetcetc] As shown above, in real life it will be much *less*
reliable.
As *speculated* above. Things like this are shown by experiment, and
experiment only. If either of us wants to show that threads or
synchronous is better, the only way to do so is to actually load a
system with many such plugins and plot the results. There is a reason
parallel computing literature is full of such plots, and nobody cares
about performance arguments that lack them whatsoever. It's simple to
convincingly argue just about anything "would" be faster - and be wrong.
This is true even sequentially on modern architectures, and it's
*really* true when threads get involved.
More to the point though, your argument is convincing - and a straw man
(see below). More importantly, I don't care, and it was a mistake to
ever indulge it.
The point of this was to invent and implement a bunch of LV2 things,
including block length restrictions in general (something you are about
the only advocate of around here, ironically).
Perhaps convolving in this way is completely idiotic. Great, fine,
fantastic, DON'T CARE, because that is not the point. I never claimed
this plugin was the best way to do convolution (I explicitly did the
exact opposite), so stop arguing against nothing.
It's not the best convolver.
It's not the best way to convolve.
It's not the best way to use libzita-convolver.
It's not an IR.lv2 replacement.
It's not recommended for use, by anyone, at all, for anything.
It is a tech experiment. Get it?
Both (1) and (2) are simply untrue, there is *no*
relation at all between
using threads and allowable block sizes. You are really showing that you
haven't even started to understand how partitioned convolution works.
As it happens you are using the exact same confusion of concepts to make
a straw man of my argument so you can subsequently burn it. You asked
what's wrong with threads, and I made some points about why *threads* in
plugins are undesirable, in general. I didn't even say anything about
partitioned convolution.
I also don't care, and didn't write that part. Yell at Robin instead.
-dr
9:44 p.m.
On Sun, Oct 21, 2012 at 01:36:00PM -0400, David Robillard wrote:
As *speculated* above. Things like this are shown by
experiment, and
experiment only.
How apt. I've done some half year of experiments like this
while going through the four or five different experimental
architectures of zita-convolver before the first version was
released. And again the same for each update. The last version
was put on hold for three months while it was being tested by
some 'power users'. And what have you done ?? Do you have any
problematic experimental results to share ??
Not everybody designs software in the careless way you seem
to take as standard.
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
9:59 p.m.
On Sun, 2012-10-21 at 19:44 +0000, Fons Adriaensen wrote:
On Sun, Oct 21, 2012 at 01:36:00PM -0400, David
Robillard wrote:
Well, I have successfully trolled the information I wanted out you,
since you would never in a million years help me willingly.
Have a nice day.
-dr
As *speculated* above. Things like this are
shown by experiment, and
experiment only.
How apt. I've done some half year of experiments like this
while going through the four or five different experimental
architectures of zita-convolver before the first version was
released. And again the same for each update. The last version
was put on hold for three months while it was being tested by
some 'power users'. And what have you done ??
9:24 p.m.
On Sun, Oct 21, 2012 at 01:38:48PM -0400, David Robillard wrote:
On Sun, 2012-10-21 at 11:38 +0000, Fons Adriaensen
wrote:
[...]
Yes, the mutex being part of a condition variable,
used to emulate sem_t since OSX has an incomplete
implementation of those. If you'd care to analyse
*how* it is used, you'll find it's quite harmless.
In the worst case, which is extremely unlikely to
happen ever, the result will be two extra thread
(not process) switches. Which will take a few
microseconds at most, much less than other events
which do interrupt audio processing all the time.
The same happens in all my apps if they use the
ITC mechanism of clthreads. And also in some apps
I wrote and that have been used for the last ten
years or so in mission-critical roles by ESA, NASA,
JAXA and some private satellite operators. All three
of the state agencies have reviewed that code and
accepted it. Go argue with them.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Zita-convolver works on Linux and OSX
... where it locks a mutex in the process thread.
9:49 p.m.
On Sun, 2012-10-21 at 19:24 +0000, Fons Adriaensen wrote:
On Sun, Oct 21, 2012 at 01:38:48PM -0400, David
Robillard wrote:
The appropriate thing to use on OSX is mach semaphores. This code is
terrible.
On Sun, 2012-10-21 at 11:38 +0000, Fons
Adriaensen wrote:
[...]
Yes, the mutex being part of a condition variable,
used to emulate sem_t since OSX has an incomplete
implementation of those. Zita-convolver works on Linux and OSX
... where it locks a mutex in the process thread. (A "blocking in a real-time thread is
acceptable" argument)
(Hilarious appeal to irrelevant authority)
Mmhmm.
-dr
9:57 p.m.
On Sun, Oct 21, 2012 at 03:49:30PM -0400, David Robillard wrote:
The appropriate thing to use on OSX is mach
semaphores. This code is
terrible.
I'd be most happy to replace the current code with
some using Mach semas. Patches will be much appreciated.
> (A "blocking in a real-time thread is
acceptable" argument)
Yes, in some cases that is acceptable.
> (Hilarious appeal to irrelevant authority)
Much more relevant than you are.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
20 Oct
20 Oct
8:19 p.m.
On Sat, 2012-10-20 at 11:44 +0000, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 12:14:29AM -0400, David
Robillard wrote:
By "zero latency" here I mean zero latency, synchronous, and strictly
hard real-time safe, i.e. no buffering and no threads whatsoever.
Also note I did not say fixed. This plugin requires a power of 2 buffer
size, not a fixed one. That is a separate feature (which also exists in
LV2 1.2.0 but there is no corresponding test plugin yet).
What I really meant was: it inherently requires restrictions, period
(perhaps not those exact ones). This is a new feature.
convoLV2 is in an early stage of development and
is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as an instantiate option
* Block length must always be a power of 2 (a required feature)
See the links in the README and on the github page for details about
these features. The first should be trivial to implement in any host,
which is highly recommended. The second may be difficult or impossible,
though it is trivial in hosts that run plugins directly on the Jack
cycle[1] or process files with fixed parameters.
Since you invited remarks:
ConvoLV2 uses libzita-convolver, but in a very inefficient way,
by restricting it to a single partition size equal to the process
block size. This is NOT necessary in order to obtain zero latency,
in fact the whole point of zita-convolver is that it can provide
zero latency even if most of the convolution is computed using
partition sizes much larger than the process block size.
This plugin is intended to provide latency-free
synchronous convolution,
which inherently requires these restrictions.
This is simply not true. A fixed, power-of-2 block size is NOT
necessary in order to obtain zero latency, not even if you use
multiple partition sizes. Supporting an arbitrary block size
(within some reasonable limits) is just a bit more complicated.
But it can be done quite efficienty using two Convproc instances
for example. Thirdly, for the use case of reverbs, the whole
latency issue is
just irrelevant. A reverb IR should not contain the direct sound
(since this will be mixed in separately), and in fact the first
10 ms or so should be silence anyway, they don't contribute to
the effect and just cause coloration. Which means you can adopt
a scheme that permits arbitrary block sizes by allowing one (Jack)
period of latency. Just remove as many samples from the start of
the IR to compensate.
The whole point of this plugin is to expose convolution at a low level
in a simple well-behaved plugin with no threads. This is obviously
desirable in some cases. It is more about being synchronous than
anything about time.
If that is not what you want, either do all the funny business at a
level above the plugin, or use a different plugin. We are not claiming
this plugin in its current form is the best way to do convolution in a
plugin in all cases.
Of course, as mentioned, the real point here is to announce a test
plugin for block length restrictions, so host authors can work on it.
Perhaps we will come to the conclusion that slightly different ones are
best in this case (e.g. any multiple of the minimum which happens to be
a power of 2), but any plugin that operates in this way will definitely
require some kind of restriction(s). Currently we have fixed, bounded,
and power of 2 (and any combination thereof), which is good enough until
proven otherwise.
-dr
3:27 p.m.
On 20 October 2012 06:14, David Robillard <d(a)drobilla.net> wrote:
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
I'm accepting patches to IR if anyone cares to implement the features
now seemingly made possible by LV2 so as to avoid any "kludges". I'm
sorry that I had to violate(?) your LV2 specs in order to be able to
produce a working plugin - one that was actually usable, back in
January 2011 and ever since, by actual audio engineers using Ardour.
I'd just like to note that the "inherent requirements" such a
convolving plugin poses, that you are now addressing with convoLV2
(maximum block length to be known in advance; power-of-2 buffer size),
have been raised by myself as questions and requests for features on
the LV2 mailing list sometime in early 2011, after considerable
frustration I had with LV2 while implementing IR. I'm quite happy that
LV2 is finally getting there, but I'm afraid that I have lost all
appetite for the sight of any LV2 specs so it is very unlikely that I
will be implementing any un-kludging, spec-un-violating changes
myself.
Thanks,
Tom
7:45 p.m.
On 10/20/2012 03:27 PM, Tom Szilagyi wrote:
On 20 October 2012 06:14, David Robillard
<d(a)drobilla.net> wrote:
Tom. I had a look the IR.LV2 code and before setting out on this one and
wanted to patch IR.LV2 but that turned into a rewrite. The three main
reasons for that are
1) IR.LV2 does buffering to align small block-sizes to an internal
block, thereby introducing latency.
2) IR.LV2 shares an instance pointer with the GUI
3) IR.LV2 spawns its own threads (for loading and processing IRs and
also inside libzita-convolver). The threading seems to be responsible
for most of the crashes of IR.LV2 that I experience)
(1) could be dealt with, but (2) and (3) are a big NO in LV2. Changing
IR.LV2 to uses Atom-messages and use the worker-thread model requires a
major re-design of IR.LV2. Patches are not suitable to address that.
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
I'm accepting patches to IR if anyone cares to implement the features
now seemingly made possible by LV2 so as to avoid any "kludges". I'm
sorry that I had to violate(?) your LV2 specs in order to be able to
produce a working plugin - one that was actually usable, back in
January 2011 and ever since, by actual audio engineers using Ardour.
indeed. Thanks a bunch for your effort.
I'd just like to note that the "inherent
requirements" such a
convolving plugin poses, that you are now addressing with convoLV2
(maximum block length to be known in advance; power-of-2 buffer size),
have been raised by myself as questions and requests for features on
the LV2 mailing list sometime in early 2011,
LV2 is moving slowly but steadily. I had the same experience. different
topics. In particular static init arguments:
http://lv2plug.in/trac/ticket/6
My intent is not to write a IR.LV2 competitor, but a LV2 convolution
plugin without GUI at all (to be used in setBfree). I want to pass
parameters to the plugin on startup and never change them again later
(much like jconvolver). It turned out this is not possible with LV2 - at
least at this point in time. Also, since there are no dynamic ports in
LV2, the very flexible channel mapping of convoLV2 needs to be
effectively hard-coded.
Luckily, drobilla uses the opportunity to start addressing some of the
shortcomings and there may be more down the road.
after considerable
frustration I had with LV2 while implementing IR. I'm quite happy that
LV2 is finally getting there, but I'm afraid that I have lost all
appetite for the sight of any LV2 specs
If I may say so, the specs have evolved and quite a lot and are getting
nicer and nicer every day.
so it is very unlikely that I
will be implementing any un-kludging, spec-un-violating changes
myself.
If that is the case, maybe you can consider helping up getting convoLV2
on its way. Since my intent to make convoLV2 a GUI-less plugin does not
seem to work out, there'll be need for a GUI at some point in time. On
this end there will be overlap with IR.LV2.
ciao,
robin
8:42 p.m.
On Sat, 2012-10-20 at 19:45 +0200, Robin Gareus wrote:
[...]
If that is the case, maybe you can consider helping up
getting convoLV2
Since my intent to make convoLV2 a GUI-less plugin does not
seem to work out, there'll be need for a GUI at some point in time.
I still want the plugin to be usable without a custom GUI...
-dr
21 Oct
21 Oct
12:41 p.m.
On 20 October 2012 19:45, Robin Gareus <robin(a)gareus.org> wrote:
Tom. I had a look the IR.LV2 code and before setting out on this one and
wanted to patch IR.LV2 but that turned into a rewrite. The three main
reasons for that are
1) IR.LV2 does buffering to align small block-sizes to an internal
block, thereby introducing latency.
Not really important to the core discussion, JFTR let me point out
that this is not entirely true. There are two "versions" of IR (they
should have been called branches, because that's what they really
are). IR.lv2 version 1.2.x is fully zero latency in the sense that you
guys (and myself too) really like it to be. Version 1.3.x was
introduced after I realized that when automated within Ardour, the
plugin's run() will be called with random non-uniform blocksizes, so
to make it work the additional buffering needed to be introduced. I
have tried to clearly document this on the plugin's webpage. Version
1.2.x gets a new release every time version 1.3.x does, so they are in
sync with each other. I still use 1.2.x myself because I typically use
IR on busses and even though the plugin reports the latency to the
host via LV2, in Ardour 2.x there is no latency compensation (I
haven't had the time yet to test drive A3 enough to make me convinced
to move my production projects from A2 to A3).
2) IR.LV2 shares an instance pointer with the GUI
3) IR.LV2 spawns its own threads (for loading and processing IRs and
also inside libzita-convolver). The threading seems to be responsible
for most of the crashes of IR.LV2 that I experience)
I use IR almost daily on quite sophisticated A2 projects with more
than 10 IR instances on a 4-core machine. I'm quite puzzled by your
remark because I don't really experience any crashes I can relate to
IR. (yes, A2 crashes sometimes, but it is seemingly due to my heavy
use of editing features, since it never crashes when
instantiating/adjusting IR, only when I edit regions and do other
stuff.) Naturally, with the above kludges, I have no idea about other
hosts.
(1) could be dealt with, but (2) and (3) are a big NO in LV2. Changing
IR.LV2 to uses Atom-messages and use the worker-thread model requires a
major re-design of IR.LV2. Patches are not suitable to address that.
Then I'll have to do the rewrite at some point, but it probably won't
happen until IR stops working in the latest stable release of Ardour.
Hopefully the plugin you guys are doing now will help me as a case
study in how to do these things the proper way in LV2.
Thanks,
Tom
12:46 p.m.
On 21 October 2012 12:41, Tom Szilagyi <tomszilagyi(a)gmail.com> wrote:
Not really important to the core discussion, JFTR let me point out
that this is not entirely true. There are two "versions" of IR (they
should have been called branches, because that's what they really
are). IR.lv2 version 1.2.x is fully zero latency in the sense that you
guys (and myself too) really like it to be.
Sorry, just clarifying myself. You are probably right about the
problems with multi-threaded processing (and the implications of hard
realtime-ness) in the plugin, I was just referring to processing
latency.
in Ardour 2.x there is no latency compensation
on busses. (that's what I meant)
Tom
3:04 p.m.
On Sun, Oct 21, 2012 at 12:41:45PM +0200, Tom Szilagyi wrote:
I use IR almost daily on quite sophisticated A2
projects with more
than 10 IR instances on a 4-core machine. I'm quite puzzled by your
remark because I don't really experience any crashes I can relate to
IR. (yes, A2 crashes sometimes, but it is seemingly due to my heavy
use of editing features, since it never crashes when
instantiating/adjusting IR, only when I edit regions and do other
stuff.)
Exactly the same here (not using the LV2 but jconvolver).
Another example. Although the system is officially still
'experimental', Italian radio is now routinely using the
Eigenmic for live broadcasts of concerts. Which probably
means they trust the mic and the software used to process
its signals in real time. This now uses zita-convolver,
doing 32 * 16 simultaneuous convolutions on a Macbook,
the same which at the same time also runs their DAW, and
various other software such as a panoramic video display
which has the moving spot mic directions generated by the
convolutions superimposed on it. They now have several
hundreds of hours using the system, and the convolution
processor has never failed (other parts have). And yes,
the processsor does use multiple partition sizes and
threads.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
3:48 p.m.
On 10/21/2012 12:41 PM, Tom Szilagyi wrote:
The crashes here are not related to convolution engine, but likely
because of IR.LV2's background configuration thread. I only get crashes
when it's recalculation envelopes or re-loading IR files. It is not
always reproducible and it's hard to get a backtrace when it's running
inside Ardour. I can try with jalv.gtk.
Once it's running and I don't change parameters it is stable.
I'm using ir.lv2-1.3.1 with libzita-convolver-3.0.1 (both from debian).
I've only just seen that 1.3.2 is out; yet my production machine is
squeeze with gtk-2.X, so I can't upgrade easily, but I'll recompile it
at the next convenient update breakpoint.
ciao,
robin
On 20 October 2012 19:45, Robin Gareus
<robin(a)gareus.org> wrote:
[..]
3) IR.LV2
spawns its own threads (for loading and processing IRs and
also inside libzita-convolver). The threading seems to be responsible
for most of the crashes of IR.LV2 that I experience)
I use IR almost daily on quite sophisticated A2 projects with more
than 10 IR instances on a 4-core machine. I'm quite puzzled by your
remark because I don't really experience any crashes I can relate to
IR.
20 Oct
20 Oct
8:39 p.m.
On Sat, 2012-10-20 at 15:27 +0200, Tom Szilagyi wrote:
On 20 October 2012 06:14, David Robillard
<d(a)drobilla.net> wrote:
Sure, you wrote the plugin using what you had available at the time.
Sorry, this was not meant as a criticism of IR.lv2. convoLV2 has
different goals and a different approach, and if it was based on IR.lv2
it would be a totally incompatible fork anyway.
-dr
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
I'm accepting patches to IR if anyone cares to implement the features
now seemingly made possible by LV2 so as to avoid any "kludges". I'm
sorry that I had to violate(?) your LV2 specs in order to be able to
produce a working plugin - one that was actually usable, back in
January 2011 and ever since, by actual audio engineers using Ardour.
4369
days inactive
4370
days old
linux-audio-dev@lists.linuxaudio.org
28 comments
5 participants
participants (5)
-
David Robillard -
Fons Adriaensen -
hermann meyer -
Robin Gareus -
Tom Szilagyi