Rust Audio

Testing LV2 plugin from the book makes Carla crash

I’m currently learning the basics of LV2 and audio programming in general, after following the amp plugin from the lv2 book I’ve tried to test if I could at least load the plugin, the end result is just like the title, Carla just crashes in my face.

Here’s the Carla output after running from a terminal

      Carla 2.1.1 started, status:
      Python version: 3.8.2
      Qt version:     5.12.8
      PyQt version:   5.14.1
      Binary dir:     /usr/lib/carla
      Resources dir:  /usr/share/carla/resources
    Frontend pixel ratio is 1.0
    libjack.so.0 loaded successfully!
    fish: “carla” terminated by signal SIGSEGV (Address boundary error)

I’ve checked the code and the .ttl files quite few times to see if something is wrong but nothing at all.

Hey REIS0,

First of all, welcome to the discourse!

Interesting: Carla and all of it’s dependencies are up-to-date, and the amp plugin doesn’t do that complicated things. Could you maybe provide more information? Which Linux distro are you using? Is it a 32-bit or a 64-bit installation? If you have it installed, which version has your LV2 package? Which exact book are using? Until recently, there were some other sketches out there that might contain faulty code. Also, could you maybe provide the exact code you’ve written? Have you tried to install and load the original plugins?

Thanks for the welcome

I’m currently using Pop_OS! 20.04, everything 64-bit, if by package you mean the crate I’m using the 0.5.1 version. The book I’m currently is the one linked in the git repo, since is the only I can actually open, the other versions only have broken links.

I’m tracking the plugins in the git repo here

The original plugins work without problems, I’ve checked their code with mine but so far could not find anything that could be causing this problem.

I found some issues:

  • “cp -r eg-amp-rs.lv2/ target/lv2/” doesn’t behave the same depending if target/lv2 exist or not. So it’s wise to add “mkdir -p target/lv2” before.
  • your amp.ttl have a missing closing double quote line 45, i think this is the issue making carla crash
  • your ttl files contain some other errors, jalv complain about it when running your plugin

I have also remarks:

  • “inplacebroken” is unecessary and undesirable since some host doesn’t support this feature. I need confirmation, but this is mean to be used for plugin that modify the input buffer, and this is impossible with rust-lv2.
  • seem your are using the --target using same target as your host, i wonder why.

Thanks for the feedback, yeah as you said it was the quotes in line 45.

I’ll take this advice when I continue the book, regarding the “inplacebroken” I can’t say anything since I’ve just begun.

The target was just me trying to recompile this at 2am with different methods to check if this was causing the error, I’m also going to rewrite this part.

This is wrong and an important requirement for Rust plugins: Generally, a host may allocate input and output ports at the same memory locations in order to force the plugin to work in-place. This reduces the required memory and cache misses, but due to the implementation of Rust-LV2, this would mean that there will be mutable slice and an immutable slice pointing to the same memory at the same time, which obviously isn’t allowed in Rust. Therefore, a Rust-LV2 plugin may never work in-place and has to communicate that to the host by requiring the inPlaceBroken feature.

After reading again the spec (and discussing on #lv2), yes you’re right, what i said is only one of the possible “inPlaceBroken” issues. So, i think a plugin is not “inPlaceBroken” if you don’t modify the input buffer and if you don’t read any input[n] after writing any output[n]. The first condition is guaranteed by rust-lv2, and the second can be easily ensured by the plugin developer.

I would be cautious with saying that the developer can assert these conditions. Remember: If you have a mutable and an immutable reference, the compiler assumes that these will never reference the same memory. This is a valuable invariant for optimizations, because it means that rearranging reads and writes will not have an effect. Therefore, even if the code looks like these conditions are met, the resulting binary might not.

I saw somewhere that Rust compiler doesn’t reorder or optimize read/write that happen through FFI, but i can’t remember where i saw that.

Ooops, in fact Janonard may right, see the warning here. If at some place your casting some pointers to a mutable references, you promise compiler that those pointers aren’t aliased (does rust-lv2 do this cast ?).