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
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