#24 LV2 version of the cabinet does not affect sound.

[Rafael Vega]

I am running Guitarix compiled from latest version in git (https://aur.archlinux.org/packages/guitarix-git/) when I load the GxAmplifier-X or the GxCabinet LV2 plugins under Ardour 4, the sound is not affected when I choose different cabinet models or their parameters. On the stand alone guitarix app, changing the same parameters change the sound in an obvious way.

[Rafael Vega]

I just loaded the same plugins in Carla LV2 host and they work as expected, I can only see the problem in Ardour... :(

[brummer]

Something must have changed in ardours plugin handling. When the cabinet didn't work, it means a supported feature in the Host is missing. When you start ardour from terminal, you will get a output from the plugins when you load them.
That will show which feature is missing in Ardour now. (Propperly the worker or the buffsize extension)

[Rafael Vega]

Thanks for the reply :)
I ran ardour from the command line and added the plugin but I don't see any message pertaining guitarix or LV2...
What you are saying is that Ardour is probably missing the "worker" and/or the "buffsize" LV2 extensions?
I'll try to take this to Ardour IRC but I'm not sure I understand the problem.

[Rafael Vega]

I had to compile ardour with debug capabilities in order to get messages out of it. Attached is the log. There are many messages pertaining guitarix now but I can't see anything stating there are missing features in the host.
Maybe I have to use a debug version of the plugin? how?

[brummer]

There is no debug version of the plugs. but they puts out on default, when something goes wrong.

Indeed, there is nothing indicate a missing feature, but, there is one thing makes me wonder. Usualy GxAmplifier-X puts out

using block size: 128
mlock 463501 bytes

here I only see

mlock 438877 bytes

I'm missing the using block size line.
And, usualy, when GxAmplifier-X missing the blocksize, it put's out

No maximum buffer size given

So, something is going starnge here, but, unfortunatly I haven't had time before next week to build Ardour and look into it.

By the way, have you tried the GxAmplifier-Stereo-X version, maybe this has to do with the double instance handling of Ardour. When I remember right, there was a problem once in Qtractor, related to this. Rui have fixed that reall sone.

regards
hermann

[brummer]

I just see that Ardour reqiers liblilv 0.21.3 (from drobilla SVN) to handel LV2 plugs propper.
https://community.ardour.org/node/8878#comment-41061

[Rafael Vega]

Same issue with mono and stereo versions. Also, Robin Gareus on the Ardour IRC suggested this might be an issue: https://github.com/FFTW/fftw3/issues/16 However, KXStudio's version of audio plugins are statically linked to libraries (as suggested by Robin, also) and the same issue is visible in Ubuntu 14.04 with Ardour and Guitarix from KX repos.

Thanks for looking into this, whenever you have time, of course!! :)

[Rafael Vega]

I uncommented some printf statements in gxcabinet.cpp and the output did change, see the attachment.

[brummer]

Jep, that looks correct.
So, if it is the fftw3 issue, you could build guitarix with the --convolver-ffmpeg flag, which use ffmpeg instead of fftw3 for the convolver.
Full config line for best performance is:
./waf configure --prefix=/usr --includeresampler --convolver-ffmpeg --optimization

maybe I need to set the use of ffmpeg as default instead the fftw3.

[Rafael Vega]

From the beginning I've been using the --convolver-ffmpeg flag.
Also, I installed lilv from svn and re-compiled Ardour, still the same issue.
Finally, uncommenting printf statements in src/LV2/gx_amp.lv2/gxamp.cpp I get "cabinet convolver updated" in ardours output when I change the cabinet model.
I think this is the farthest I can get in my search for now.
I hope you can figure out what I couldn't. Let me know if I can be of any help.
Cheers!

[Rafael Vega]

I also opened this issue in Ardour bug tracker: http://tracker.ardour.org/view.php?id=6565

[Robin Gareus]

found the issue:

gx-cabinet uses http://lv2plug.in/ns/ext/buf-size/#maxBlockLength or rather the bufz_max instantiation opion as current buffersize for GXSimpleConvolver.

In Ardour, maxBlockLength is 8192 and the current block size is smaller than (or equal to) 8192 samples. The current block-size used when running the plugin can change any time (user changes latency/buffersize, on export, split-cycles when looping, plugin-analysis,...).

Most other LV2 hosts use the current jack block-size at application start, which is why gx-cabinet works in jalv.. until the user runs jack_bufsize and changes it. In that case gx-cabinet either turns into a noop if the new block-size is smaller or produces odd sounds (half-way signal passhtough) if the new buffersize is larger.

[brummer]

But, why have you change that in Ardour?
GxConvolver use MaxBlockLength because "ALL" hosts use it to indicate the current buffer size, that includes Ardour as well, as least the last time I've checked that.
So now, we have the situation that Ardour handle that different then all other hosts.

[Robin Gareus]

the change was in 4.1 because various plugins crashed.
The issue was eventually found with rkrlv2: http://tracker.ardour.org/view.php?id=6498

Using max as current is/was a mistake. See for example the guitarix/jalv issue. Change the jack buffersize while running will cause problems.

[falkTX]

but that's because jalv is broken, as it does not notify the plugin about such changes.
if bufsize is a required feature the plugin will stop working when the values mismatch.

not sure why you insist so much on this.
I already told you options->set is there to notify the plugin about such changes.

Carla has been doing this for a while now.

[falkTX]

We need to come with something to let the plugins know the real current buffer size.
Using the maxBufSize value was wrong to begin with, but LV2 doesn't have a property for this yet.
I can certainly make a specific property for this.
But the host will have to support options interface to make sure the plugin knows about possible changes.

[Robin Gareus]

The current-buffersize is passed at run() every time, no extention is needed.
For the case at hand (zita-convolver), it isn't a big deal to allow variable buffersizes.

[falkTX]

yes, the current buffer-size is passed at every run() but we can't do allocations there.
complex plugins will need to know the buffer size that is going to be used for run() in advance.
I know it's only a hint, but knowing that value (the maximum that is going to be used anyway) can help to optimize things.

All other major specs have a way to know this value, LV2 is the only one that doesn't.

Anyway, this is not strictly a bug about guitarix but LV2 itself.
I plan to address this myself very soon.

[Robin Gareus]

"complex plugins need to know the MAX possible bufffersize in advance" -- there fixed it for you :)

What use-case is there to pass the current-buffersize both in run() and out of band? It can't be in sync anyway. run() is realtime thread, but announcing the current which can change any time in a separate thread sounds like a really bad idea that will lead to horrible DSP that should rather be re-designed.

What would a plugin do if it changes? Go offline, pass silence while re-initialization/allocation/... is done (worker thread) and then continue? What if it changes every cycle?

Another option is to add a ringbuffer (and add latency): decouple the internal processing using fixed block-length (that's what threaded zita-convolver does).

If a plugin requires min == max == current block-size, the only viable option is to re-instantiate the plugin every time the block-size changes.

[brummer]

Be aware that guitarix was one of the first applications which provide a buffersize change option in the menu to the users, and guitarix handle that for all it's plugins very well. So please, stay tuned.
Be also aware that gx-plugins never ever ( under no circumstands) crashed a host, even now, were you decide to change the information base you give to the plugins, we talk about a audible missing, not about a chrash.
And again, it's ardour who changed it's behaive, which leads to this issue.
Internal gx plugs handle all that nicely, but, without notice from the host about changes, there is no way to produce the requestet audio.
Adding latency isn't a option for me, sorry about that, but nope, no way. Note that LV2 plugs may also be used in a live environment (MOD).
I've told the rkr dev about the issue with the ardour analyse tool, and now, I feel like I've bitten in my one leck.
Also, I'm not aware about any guitarix/jalv issue? (beside my very own discussions with dave which may be not so amussed some time)
However, what I didn't understand is, for what is it worse to tell plugins about a fixed max buffersize? For correctness a plugin needs to know the buffersize for any given circle, and, it needs it to know it before the circle starts. Thats how we do it in guitarix. We use the time between jack callbacks to inform plugins about changes and give them the chance to allocate what they need. If they are not ready, they get passed by and get called the next cicle.

[Robin Gareus]

Yeah no crashes (kudos), just unprocessed audio.

Ardour was always wrong, since it was possible for the buffersize to exceed the max.
The current behavior is as intended by http://lv2plug.in/ns/ext/buf-size/#maxBlockLength

As faltkx points out, not using it as instantiation option but using get(), set() to query the value dynamically (alike the jack_bufsize callback you mention) would be a way out.

Still it won't solve the case for changing buffersizes seamlessly. Or in the non-theaded zero-latency zita-convover case for non-power-of-two sizes.

[brummer]

Robin, so how do we get out of this, Ardour is the only host I'm aware of, which handle this extension in this way. So, I rewrote my convolver implementation to cover this, one host, because you decide that maxBlockLength have to be the maxBlockLength, were all other hosts use it as currentBlocklength, because some (advandeced, complex) plugs wont implement streaming when buffersize changed for your analyse plugin? Come on, . .
You are realy belive there is no need to tell a plugin what buffersize it has to expect, on init, but the max size? Umpf,
Great, by the meaning of the word, you are right, for sure, but, do you feel the pain, do you? (Just joking around here, please dont take it to serius, need (use) just a little bit help of my friend (sarcasm).
You know, that is exactly the point were comercial developers throwing there twols.

[Robin Gareus]

Probably jalv and other LV2 hosts will follow because other plugins expect max to be max and the lv2 specs are clear: maxBlockLength is maxBlockLength :)

If you really need currentBlockLength, falktx said he's writing an lv2 extension for this speficic case. I can't bring another sane option to the table.

Adding a ring-buffer to the host and guarantee a fixed-block length for plugins that require this (at the cost of latency) is not a nice solution but that's the eventual plan for lv2plug.in/ns/ext/buf-size/#fixedBlockLength (currently not supported)

I'd love to have David's clarification on this:
If I read the spec correctly: When the buffersize is passed as instaniation parameter it is a fixed value (that's what gx-cabinet currently reads). But when the maxBlockLength Option is used as LV2_Descriptor::extension_data() it can be dynamic. (http://lv2plug.in/ns/ext/options/#interface) that's what carla offers via set(), get(). Ardour could support that too, but does not do that yet. I'd like to get feedback from drobilla about this (he knows but is busy). Actually he wrote most of the ardour/lv2 code to begin with..

PS. I'm facing similar issues with convo.lv2 BTW.

[brummer]

It takes me les then 5 minutes to implement a buffsize check and set, but, the question which comes up in my mind is, what, why the hell we didn't have a callback for this, why every plugin have to check this value on every circle, every micro secound, isn't it stupid?
Come on, it is. Connect a slot and be done, only act when get called.
This is not the only value which needs to be checked on any circle in LV2.

[falkTX]

I'm getting tired of this conversation.
The plugin does not exactly need to know the real current one as that can change with some hosts like Carla and Ardour.
But it needs to know a sane maximum value, not a big static one like ardour has right now.

Variable buffer sizes are fine in Ardour, but even those have a max value that is different from the static 8192.
When Ardour is running with ASIO or JACK drivers, do we really expect some of its run() calls to use 8192 frames?

Now, you'll say that value is used during export but that the entire point of reporting the changes to the plugin!
How is this hard to understand!?

When processing the plugin live, tell it what is the maximum frames it should expect.
No, a static 8192 is not a good value.
When going offline/freewheel, then report to the plugin about the buffer size change.
Also set the freewheel port to "ON" if the plugin provides one.
That way it will know it can do reallocations if necessary.
When the offline mode is finished report back to the plugin the proper max buffer size again.

If Ardour does this everyone will be happy.

What I personally don't like (and I'm sure most devs are the same) is Ardour using a static max value for everything.
Although it's technically correct, it's a very selfish & lazy thing to do.
That's why I want to introduce a new property, because I know Ardour will very likely not change.
Then plugins can depend on this new (correct) property.