-double and -quad breaks certain plugins

[magnetophon]

When I do:

git clone https://github.com/magnetophon/faustCompressors.git
cd faustCompressors
faust2lv2 -gui RMS_FBcompressor_peak_limiter.dsp

I get a working plugin.

When I do:

faust2lv2 -double -gui RMS_FBcompressor_peak_limiter.dsp

I get a plugin that segfaults both jalv.gtk and ardour.

-quad also breaks it.

Another plugin from the same repo does work:

faust2lv2 -double -gui FFcompressor.dsp

[Albert Graef]

Well, if you add -double then the plugin assumes that all sample buffers passed between host and plugin will be double. If the host passes single precision float buffers instead (which I assume both Ardour and Jalv do) then the plugin will try to access nonexistent memory.

So don't do that. :) It's the responsibility of the plugin programmer to get that right. faust or faust2lv2 can't possibly know what your host's native sample format is.

[Albert Graef]

Another plugin from the same repo does work:

Then that's just an accident. But the plugin will most likely write into memory that it's not supposed to mess with anyway.

[Albert Graef]

Hmm, no, scratch that. faust -double only seems to have an effect on the sample data used internally, the callback interface uses FAUSTFLOAT which is float in either case by default. Will have to take a closer look with a fresh mind in the morning.

[magnetophon]

Great. Thanks for the quick response. I hope you'll find the issue tomorrow! :)

[Albert Graef]

I didn't say which morning. ;-) The problem is that the gui part of the architecture was done by a student for his master thesis, so I don't know that part of the code as well as my own.

That said, I suspect that it's a float/double mismatch in the gui part somewhere, so I'd suggest that for the time being, as a work-around you just build the non-gui version and go with the generic host-provided GUI instead.

[magnetophon]

OK, thanks. fwiw: Most of my plugins are fine when compiled with -double.

[Albert Graef]

Do you have a gdb backtrace or a core dump of one of the plugins that crashes? That would be helpful.

[Albert Graef]

Cool, thanks. Is that bt from the RMS_FBcompressor_peak_limiter.dsp plugin that you mentioned?

[magnetophon]

Yes. It says so right in the second line. ;)

[Albert Graef]

Well, it's been a hard week.

[magnetophon]

No worries. I'm sure you remember my f***ups in these areas.

I just discovered another interesting thing: When I compile drumDuxpander.dsp from the same repo without -double, it runs, but it seems to be in bypass.

That is: I can not get it to do any gain reduction.

[Albert Graef]

Does that also happen when you compile without -gui?

[magnetophon]

Yes, without -gui it's the same. As a matter of fact, faust2jaqt has the problem too, so it's an upstream faust issue, and I'll report it there.

Note: I'm talking just about the drumDuxpander bypass issue here. The original issue still stands.

[magnetophon]

reported: https://github.com/grame-cncm/faust/issues/117

[magnetophon]

I tried to come up with a minimal example for the original issue, but I got stuck.

This is what I found out so far, using faust-2.5.21:

• It is only triggered with faust2lv2 using -gui plus -double or -quad.
• It needs a certain amount of declare statements to trigger.
• it only triggers with high amounts of elements: 2^16 to 2^18. depending on the surrounding code
• just the high number (even 2^25) for that parameter will not trigger it, it needs the above conditions.
• it also only triggers with smooth(0.99) inline. Oddly enough, when you use the function content instead of the call, it works.

first wget https://github.com/magnetophon/faustCompressors/raw/master/slidingReduce.lib

 declare name "test";
// comment out one of these lines and it runs:
declare foo "i";
declare bar "j";

// this third declare is only needed to trigger a bug with:
// _<:par(i,4,_+i:slidingSumN(s,2:pow(16)): si.smooth(0.99)):>_
// declare another "k";


import("slidingReduce.lib");



process=
  // runs:
  // slidingSumN(s,2:pow(18))     : (_*(1.0 - 0.99) : + ~ *(0.99))
  // doesn't, even though it's equivalent:
  slidingSumN(s,2:pow(18))     : si.smooth(0.99)

  // runs, even though there are way more elements
  // slidingSumN(s,2:pow(25))

  //runs:
  // _<:par(i,2,_+i:slidingSumN(s,2:pow(17))):>_ : si.smooth(0.99)
  // doesn't
  // _<:par(i,2,_+i:slidingSumN(s,2:pow(17)): si.smooth(0.99)):>_
  // runs:
  // _<:par(i,2,_+i:slidingSumN(s,2:pow(16)): si.smooth(0.99)):>_
  // doesn't run, but only if there's another declare
  // _<:par(i,4,_+i:slidingSumN(s,2:pow(16)): si.smooth(0.99)):>_
with {
  // runs:
  // s = int(1);
  // doesn't:
  s = int(param);
  param = hslider("param",0.1, 0.0001,   1,   0.001);
};

I don't know how to troubleshoot further.

[Albert Graef]

Thanks. I can confirm that it crashes with jalv.qt when building with faust2lv2 -qt4 -double or -quad:

#0  0x00007fffd115344f in LV2PluginUI::init_meta() [clone .part.468] ()
    at /home/ag/.lv2/test.lv2/testui.so
#1  0x00007fffd115641c in instantiate(_LV2UI_Descriptor const*, char const*, char const*, void (*)(void*, unsigned int, unsigned int, unsigned int, void const*), void*, void**, _LV2_Feature const* const*) ()
    at /home/ag/.lv2/test.lv2/testui.so
#2  0x00007ffff7597400 in suil_instance_new () at /usr/lib/libsuil-0.so.0
#3  0x00000000004091ac in  ()
#4  0x000000000040ab7c in  ()
#5  0x00000000004055e9 in  ()
#6  0x00007ffff5852f4a in __libc_start_main () at /usr/lib/libc.so.6
#7  0x0000000000405b39 in  ()

It does crash there in init_meta(), so there's a relationship with meta data being used, but that's just a symptom I'd guess. The real culprit is probably some bad memory access earlier in the Qt GUI code.

Anyway, thanks for the great example, that's something that I can go about investigating now. :)

[magnetophon]

Any news on this?

[Albert Graef]

Sorry, way too much more important stuff on my TODO list right now.