Re: [LAD] ANN: convoLV2 0.2
On Mon, Oct 22, 2012 at 02:31:35PM +0200, Stéphane Letz wrote: You can use semas on OSX, you'll need to use sem_open API instead of sem_init. Using here: sem_open, sem_post/sem_wait, sem_unlink/sem_close with success (In Faust Work Stealing Scheduler code). And semas are actually a slight wrapper over Mach semas. You can check that in XNU source (here for instance http://opensource.apple.com/release/mac-os-x-1068/) Except that the implementation is incomplete. And worse, some functions such as sem_init() do exist but don't work. Earlier versions of zita- convolver also required sem_getvalue() which doesn't exist or doesn't work, I don't remember. Having to do all of: destroy a sema, create a new one in the filesystem (which requires unique names), open then unlink the new one, just to reset its counter to zero is too much a hack for it to be acceptable. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Mon, Oct 22, 2012 at 9:03 AM, Stéphane Letz l...@grame.fr wrote: Le 22 oct. 2012 à 14:50, Fons Adriaensen a écrit : On Mon, Oct 22, 2012 at 02:31:35PM +0200, Stéphane Letz wrote: You can use semas on OSX, you'll need to use sem_open API instead of sem_init. Using here: sem_open, sem_post/sem_wait, sem_unlink/sem_close with success (In Faust Work Stealing Scheduler code). And semas are actually a slight wrapper over Mach semas. You can check that in XNU source (here for instance http://opensource.apple.com/release/mac-os-x-1068/) Except that the implementation is incomplete. And worse, some functions such as sem_init() do exist but don't work. http://subversion.ardour.org/svn/ardour2/branches/3.0/libs/pbd/pbd/semaphore.h (work by david robillard) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
Le 22 oct. 2012 à 15:09, Paul Davis a écrit : On Mon, Oct 22, 2012 at 9:03 AM, Stéphane Letz l...@grame.fr wrote: Le 22 oct. 2012 à 14:50, Fons Adriaensen a écrit : On Mon, Oct 22, 2012 at 02:31:35PM +0200, Stéphane Letz wrote: You can use semas on OSX, you'll need to use sem_open API instead of sem_init. Using here: sem_open, sem_post/sem_wait, sem_unlink/sem_close with success (In Faust Work Stealing Scheduler code). And semas are actually a slight wrapper over Mach semas. You can check that in XNU source (here for instance http://opensource.apple.com/release/mac-os-x-1068/) Except that the implementation is incomplete. And worse, some functions such as sem_init() do exist but don't work. http://subversion.ardour.org/svn/ardour2/branches/3.0/libs/pbd/pbd/semaphore.h (work by david robillard) Even better Stéphane ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Mon, Oct 22, 2012 at 09:09:56AM -0400, Paul Davis wrote: http://subversion.ardour.org/svn/ardour2/branches/3.0/libs/pbd/pbd/semaphore.h (work by david robillard) I know about this, and it will find its way into zita-convolver some day. That does however require a major version increment, so it'll have to wait a bit. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On 20 October 2012 19:45, Robin Gareus ro...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On 21 October 2012 12:41, Tom Szilagyi tomszila...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
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. ;-) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
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. removed bullshit, sorry, no patch is needed. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sun, Oct 21, 2012 at 11:38:26AM +, Fons Adriaensen wrote: 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. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sun, 2012-10-21 at 11:38 +, 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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sun, Oct 21, 2012 at 01:38:48PM -0400, David Robillard wrote: On Sun, 2012-10-21 at 11:38 +, Fons Adriaensen wrote: [...] Zita-convolver works on Linux and OSX ... where it locks a mutex in the process thread. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sun, 2012-10-21 at 19:24 +, Fons Adriaensen wrote: On Sun, Oct 21, 2012 at 01:38:48PM -0400, David Robillard wrote: On Sun, 2012-10-21 at 11:38 +, Fons Adriaensen wrote: [...] Zita-convolver works on Linux and OSX ... where it locks a mutex in the process thread. Yes, the mutex being part of a condition variable, used to emulate sem_t since OSX has an incomplete implementation of those. The appropriate thing to use on OSX is mach semaphores. This code is terrible. (A blocking in a real-time thread is acceptable argument) (Hilarious appeal to irrelevant authority) Mmhmm. -dr signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sun, 2012-10-21 at 19:44 +, Fons Adriaensen wrote: 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 ?? 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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On 20 October 2012 06:14, David Robillard d...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On 10/20/2012 03:27 PM, Tom Szilagyi wrote: On 20 October 2012 06:14, David Robillard d...@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. 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sat, 2012-10-20 at 11:44 +, Fons Adriaensen wrote: 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. 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. 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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sat, 2012-10-20 at 15:27 +0200, Tom Szilagyi wrote: On 20 October 2012 06:14, David Robillard d...@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. 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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
You (Fons) obviously know your stuff when it comes to implementing convolution, and I'm very grateful you gave us libzita-convolver, but I have to disagree with this statement: On Sat, 2012-10-20 at 12:00 +, Fons Adriaensen wrote: 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. When you use a reverb plugin for ambience or things like the Bricasty M7 Bass XXL impulse, the coloration it is 90% of the effect you are using the plugin for. There is a whole range of useful coloration to be had by changing the pre-delay within 0-20ms. Often it will sound best with 0ms, because that how the maker of the impulse listened to it. An ambience impulse is an important part of practically every mix I do. That is why I am so happy with libzita-convolver and it's offspring :) That is also why I would *love* latency compensation on buses in Ardour. All the best, Bart. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus wrote: On 10/20/2012 01:44 PM, Fons Adriaensen wrote: 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. 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. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sat, 2012-10-20 at 21:03 +, Fons Adriaensen wrote: On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus wrote: On 10/20/2012 01:44 PM, Fons Adriaensen wrote: 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. 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. 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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: convoLV2 0.2
On Sat, 2012-10-20 at 09:54 +0200, hermann meyer wrote: 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, 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. and (for a non-native english speaker) what is mean by kludges? It means an ugly workaround. -dr signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] ANN: convoLV2 0.2
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. signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
