Crash on File Open

39 replies [Last post]
anahata
anahata's picture
User offline. Last seen 3 hours 39 min ago. Offline
Joined: 2010-10-27
Posts:

The authors of fftw seem to think that thread safety (where not implemented in some parts of fftw) is the responsibility of software developers using it, so presumably they'd agree that it's the CALF plugin developers need to take care of this.
I'm still trying to understand the issues here (thanks linuxdsp for the explanation)
It seems that making FFTW thread safe would make life easier for all plugin developers who need an FFT function, but I presume the downsides are
(a) it's a lot of work for somebody to do (close inspection of a lot of complex code to identify problem areas) and
(b) risk of a performance hit, when many applications don't need the thread safety (is that even true?)

Has anyone tried persuading the FFTW maintainers to do this?

linuxdsp
linuxdsp's picture
User offline. Last seen 4 days 6 hours ago. Offline
Joined: 2009-02-04
Posts:

risk of a performance hit, when many applications don't need the thread safety (is that even true?)

Very much depends on the implementation and / or the nature of the issue - it should not be assumed that locks are explicitly required to provide thread safety in every case, and even so, in a well designed implementation, the performance impact on a single threaded application should be minimal if at all (especially as we are told the issues cited here appear to be in the initial setup functions - not in the main processing)

seablade
User offline. Last seen 2 hours 16 min ago. Offline
Joined: 2007-01-22
Posts:

In a very real sense, that is exactly what I'm hoping wouldn't happen - its not that I object to the idea of giving users that confidence, but, because it sets out a framework / potential roadmap for 'Ardour specific' plugins - and that's at the root of the reason why I disagree with Paul's proposed method for solving this particular issue. I actually agree with (a) and (b) in Paul's reply, but I think we disagree on the implementation of it. The whole point of my argument is that by including an ardour specific fftw, if we're covinced that really is the issue with these plugins, then it inherently makes those plugins ardour-only (and ardour binary only)

And this sums up my other thoughts I couldn't type out earlier effectively. This is exactly why I would disagree with a specific packaged version of this lib for this purpose.

In my opinion LV2 is already in danger of being co-opted as a convenient means of lock-in on other operating systems by at least one well known commercial developer - most likely as an accidental but commercially useful advantage of its lack of adoption on those platforms, but I don't want to see that kind of thing or anything like it happen (for commercial benefit or just by accident of bad design choices) on linux.

Now this I disagree with:) I am fairly sure I know exactly what you are talking about, but at best there are differences, but more correctly the plugins for the most part can be used on any LV2 capable host, including Ardour. If no other host chooses to be able to host it, that is one thing, but I wouldn't call that lock in per-say when I can use it or write my own host to use it. I'll admit it may seem ambiguous at first glance, but I would argue from discussions with them that the goal is very different, and in fact close to the opposite of lock in as they do have testing happen on Ardour as well.

Seablade

seablade
User offline. Last seen 2 hours 16 min ago. Offline
Joined: 2007-01-22
Posts:

The authors of fftw seem to think that thread safety (where not implemented in some parts of fftw) is the responsibility of software developers using it, so presumably they'd agree that it's the CALF plugin developers need to take care of this.

The issue, as Paul correctly pointed out, is that it really isn't possible for it to be handled in the plugin development, short of static compilation of the lib (fftw) into the plugin I suppose so that each plugin used their own version of fftw. This of course brings with it a host of other concerns, but on the flip side, considering these are plugins we are talking about, I honestly wonder how much weight those other concerns should have at this point. Otherwise the plugin can't know the status of other plugins to make multiple thread safe calls to the same library, particularly the more you try to isolate the plugins from the DAW to prevent a plugin from crashing the DAW for instance, the more difficult this becomes and it is already pretty close to impossible.

So let me ask the question I mused about above... Would it make MORE sense for the plugin to statically compile/link fftw in place in it's own binary?

Seablade

ssj71
User offline. Last seen 1 day 20 hours ago. Offline
Joined: 2012-03-31
Posts:

To throw out my 2 cents, I agree with linuxDSP. The problem is upstream. Trying to fix it downstream won't ever fix it, only work around it. The ideal situation would be fftw becomes thread safe. Second best I think would be if there were sufficient resources to create an identically api'd fork of fftw (say the fastest fourier transform for plugins, fftp) such that upstream fftw changes can be easily merged in so it has little additional maintenance or the fork can be merged into upstream. Regardless I think the fftw maintainers need to be consulted before the decision is made. If they aren't interested in making this special use case thread safe, then it isn't the right library for plugins to use, but a minimally changed fork could be. Perhaps this is trivializing the changes required or too idealistic but it seems the most correct approach to me.

linuxdsp
linuxdsp's picture
User offline. Last seen 4 days 6 hours ago. Offline
Joined: 2009-02-04
Posts:

@seablade: I'm just far too cynical for my own good sometimes, put it down to life experience etc :) I stress this is just my opinion, and I invite people to draw their own conclusions (but perhaps not in this thread..) it still remains that while in theory LV2 is crossplatform, the reality is that, as far as I know, there isn't a free build of ardour for Windows, and there isn't yet a released build of A3 for OS X, all of which narrows down the options significantly for users of LV2 plugins as a real crossplatform solution at the present time - however that may have occurred.
I just want to see diverse choice for users (and developers) and that includes choice of DAW and compatible plugins (on any OS)

Rinon Ninqueon
Rinon Ninqueon's picture
User offline. Last seen 5 weeks 8 hours ago. Offline
Joined: 2013-10-27
Posts:

It still not works =(
I can create project, but not open again.

x42
x42's picture
User offline. Last seen 22 hours 54 min ago. Offline
Joined: 2006-11-05
Posts:

for reference: https://github.com/FFTW/fftw3/issues/16

fftw authors acknowledge the problem and a fix is underway.

Meanwhile calf-plugins have removed their fftw dependency and KXStudio provides statically linked binaries for many plugins to circumvent threading issues.

tptptp
User offline. Last seen 2 weeks 6 days ago. Offline
Joined: 2014-01-30
Posts:

Being a recording noob, I recently discovered the Calf plugins and used them on an old project as a learning exercise, only to run into this issue when saving. As suggested in an earlier post, recovery was possible through editing the .ardour file. In my case, I only had to disable the 5 band EQ plugin instances, as I did not use any of the other EQs.

Will the fix to fftw/Calf be in the Ubuntu Studio 15.04 release, or should I install the Calf plugins independently?