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
[LAD] Plugin block length restrictions
I have explicitly asked about block length restrictions on l-a-d several times, but of course that doesn't work. Setting up an idea to be flamed works wonderfully though (mining that most plentiful resource of assholes on mailing lists). The convoLV2 announcement served this purpose nicely. In summary: Convolution is the only reason anyone has come up with for a power of 2 block length restriction. Apparently that is wrong. Only one argument has ever been posed for a fixed restriction, and that was wrong too (outside LADSPA anyway, where we are not forced to use control ports). So, unless anyone has new compelling examples, we have some new implementation recommendations for the block length restrictions defined in LV2 1.2.0: * Fixed and power of two can be difficult or impossible to implement, and are not useful, so hosts should not bother trying to implement either (except where it is trivial), and plugins should not expect them to. * The remaining restrictions, minimum and maximum, are needed to do some things without latency, and are useful for performance reasons, so hosts should try to implement this if possible. Plugins should only require these if absolutely necessary, since some hosts may not be able to implement minimum in particular. convoLV2 is an example of a plugin with minimum and maximum restrictions. As before, all hosts should implement passing the maximum length to the plugin, which is often required and easy to do. There is one issue related to minimum, buffer alignment, which is useful for SIMD (e.g. using SSE). This has not yet been addressed in the specifications. -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] Plugin block length restrictions
On Sun, Oct 21, 2012 at 04:24:16PM -0400, David Robillard wrote: * Fixed and power of two can be difficult or impossible to implement, and are not useful, so hosts should not bother trying to implement either (except where it is trivial), and plugins should not expect them to. Neither fixed nor power-of-2 are strictly required for zero-latency convolution although they make it somewhat easier to implement. For the simple reason that convolution is not a block processing algorithm in the first place, even if the most efficient implementations use block processing. The next N output samples depend only on the next N input samples (and previous ones) for any value of N. So it is always possible to allow a call to process() for an arbitrary N samples. That does not mean that there are no real block processing algorithms, which do not share the property mentioned above, and which require a fixed M of input samples even to produce a single output sample. Not because of the implementation but because of the nature of the algorithm itself. For example most of the processing inside JAMIN is of that type, as will be almost all algorithms that perform spectral processing, e.g. time stretching, morphing, and the like. Given that, claiming that fixed and power-of-2 block sizes are 'not useful' is a mistake. And for real block-oriented algorithms, processing a block is an atomic operation, and it would be futile to try and change a parameter value anywhere except on a block boundary anyway. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Plugin block length restrictions
On Sun, 2012-10-21 at 21:10 +, Fons Adriaensen wrote: On Sun, Oct 21, 2012 at 04:24:16PM -0400, David Robillard wrote: * Fixed and power of two can be difficult or impossible to implement, and are not useful, so hosts should not bother trying to implement either (except where it is trivial), and plugins should not expect them to. Neither fixed nor power-of-2 are strictly required for zero-latency convolution although they make it somewhat easier to implement. For the simple reason that convolution is not a block processing algorithm in the first place, even if the most efficient implementations use block processing. The next N output samples depend only on the next N input samples (and previous ones) for any value of N. So it is always possible to allow a call to process() for an arbitrary N samples. Well, in practice arbitrary within a range, e.g. implementations may not be able to sanely deal with N = 1. That does not mean that there are no real block processing algorithms, which do not share the property mentioned above, and which require a fixed M of input samples even to produce a single output sample. Not because of the implementation but because of the nature of the algorithm itself. For example most of the processing inside JAMIN is of that type, as will be almost all algorithms that perform spectral processing, e.g. time stretching, morphing, and the like. Given that, claiming that fixed and power-of-2 block sizes are 'not useful' is a mistake. And for real block-oriented algorithms, processing a block is an atomic operation, and it would be futile to try and change a parameter value anywhere except on a block boundary anyway. (I guess I should just skip the part where I bother asking entirely and jump straight to the dubious claims. Much more effective.) Well, this effort which you have so vehemently attacked was an effort to establish this functionality in hosts. However, since convolution does not need it, as you have pointed out, I no longer plan to waste my time implementing either fixed or power of 2 in Ardour until there is a tangible reason to do so, and I doubt anybody else will waste their time either. Tangible means plugin code. Progress happens by people writing plugins, and the spec/hosts adapting to accommodate their needs. All this mailing list bullshit is just a waste of time. Serves me right for attempting to address needs that do not actually exist. Both features remain trivially supported in Jalv which can serve as a test host for anyone interested in writing such plugins. If, and only if, someone does, it will no longer be a waste of time to support them in other hosts where it is more difficult. -dr (who will think twice before posting to this toxic wasteland again) 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] concurrent access on smp
Hi With some threads running on different CPU, accessing a shared pointer (in RAM) atomically (with gcc atomic methods) my current understanding is: - each cpu has its own cache line - which is updated on every atomic read/write operation 1. is that applicable ? 2. is there a faster or more convenient method, such as storing the pointer in fast register shared among different cpu ? -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] testing
___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
