TroubledMind, do you get the same error message?
No, I get this:
Could not process audio on client audio thread 2 using remote audio thread 0: End of stream
Could not compute parameter text from normalized value: Plugin host died: Could not process audio on client audio thread 2 using remote audio thread 0: End of stream
Killing pluginhost process
Waiting for plugin host process to exit
Could not read async reply: End of stream
Plugin host process exited with code: 139
You’re not using the flatpak version of Bitwig are you?
No, installing from .deb file. Sorry, no clue what your error message means!
1 Like
I don’t understand this issue, but it always comes up. For someone who does understand - why is this always a problem with Linux? I there something wrong with the build process for VCV and modules? Or does VCV some how dynamically link to libraries and pick up the wrong one from Bitwig? Or is it just “impossible” to distribute pre-built software for Linux?
2 Likes
I don’t think it’s impossible, this used to work for me until I upgraded Linux. When I have some time I’m going to re-install the old Linux, VCV and Bitwig on a bootable drive just to prove this to myself!
I’m not a programmer but it seems to me that there is a difference between VCV and other vsts which work in Bitwig with no problem. For other vsts the .so file is the entire plugin, though there may be presets, graphical resources etc in separate folders below the main folder holding the .so file. For VCV this isn’t the case, as I understand it. The .so file in ~/.vst links to the main program files in /usr/share/VCV and and modules and saved patches in ~/.Rack. Bitwig also has external dependencies, I don’t know if this is the case with VCV. It’s this complexity which, IMO, might be behind the problem.
VCV Rack has its own libzstd, for which all symbols need to be visible as it is part of the whole Rack SDK.
Issue is that system library libzstd is required for new mesa (opensource GL drivers), and this version is not ABI/API compatible with the one provided by Rack.
When GL operations take place on some linux systems, the userspace side of the graphics driver will call some libzstd functions. Typically the system lib would be used, but since Rack has its own built-in libzstd, the built-in version is used instead. Unless both built-in and system versions are made to match, we can expect issues.
To put it in example generic terms:
let’s say a host uses libfoo.so.2 while a plugin uses libfoo.so.1, where internal ABI details changed from v1 to v2.
When this host loads the plugin that uses old libfoo.so.1, plugin actually will call libfoo.so.2 stuff.
This becomes undefined behaviour, and crashes are not unexpected.
Rack is the plugin in this example.
I see a few possible solutions:
- update libzstd to latest (bad one, will get into the same issue later on again)
- run the whole Rack out of process, so host vs plugin symbols no longer clash (has performance impact)
- place all libzstd calls under its own custom namespace (requires new Rack release and rebuilding all plugins)
4 Likes
Thank you @falkTX for that very complete answer, I think I get it. So if I could revert my Linux system to the same version of libzstd as VCV uses it should fix the problem, is that right? Although this may cause problems for other parts of the wider system that depend on newer versions of the library?
Do you (anyone?) know what version of libzstd would be compatible with VCV?
Easy to check, v1.4.5 according to Rack/Makefile at v2 · VCVRack/Rack · GitHub
But that is not a realistic solution… at some point when everyone updates (and not just archlinux with latest mesa), Rack will be broken in any recent linux distro for you and many others.
4 Likes
Thanks again @falkTX at least I understand the problem now. I’m thinking of making a separate system for music work, either dual boot or another drive, with an old Linux that I don’t update. Inconvenient though.
I’ll report this as a bug.
Please do. VCV are aware of this issue but it seems to not have a great importance to them so if this problem has made its way into such a mainstream distro as Ubuntu then they really need to know and to do something about it. We shouldn’t have to use an old distro or dual boot to use a product on a platform they apparently support.
3 Likes
Sounds like the right solution to me and I’m surprised that all bundled libraries in Rack are not called this way right from the start, as it’s a know recipe for problems, or at the very least when Rack Pro was created. One question I’m not clear on: Since Rack code is C++ it can use namespacing. C code doesn’t have namespaces. Will namespacing it’s usage in the C++ application (Rack) still work to isolate it’s symbols or will they just leak out globally because it’s C code?
It does, exactly.
2 Likes
Adding some data to this. I am running Ubuntu Studio 22.04, Bitwig 4.4.3, and VCV Rack Pro 2.0.6. Everything is working fine, no errors. So, it is possible to get it to run properly with that setup. Unfortunately I am not knowledgeable enough to help fix the errors mentioned here, but maybe it is helpful to know it can be fixed maybe?
1 Like
v2.0.6 is 9 months and 3 releases old now, so it’s not certain that your datapoint applies much. IMHO everyone should really be running v2.1.2 at this point.
I have not installed any third party drivers. My video card is AMD, I use the AMD driver for it. One possible difference is that I am using pipewire, which is not the default in 22.04 but is in 22.10 and going forward. That is the only deviation that I know of from the standard setup out of the box.
1 Like
I have not upgraded VCV Rack Pro because it was pretty buggy around release and continues to be so. 2.0.6 works and does everything I need it to and I will probably stick with it until I have a good reason not to. Especially given the info in this thread, I’m not all that inclined to upgrade to 2.1.2.
I don’t think this issue is dependent on Rack version nor pipewire. I’ve tried every release when trying to find a solution but none of them work now.
for C calls, you dont need to put them in custom namespaces. “namespacing” in C is easily achieved by just renaming all functions to have some kind of prefix. if it is unique enough (say “vcvrack_zstd_*”) then it is pretty much guaranteed to be safe to use.
Note that metadata read failures and ‘could not read async reply: end of stream’ errors were what I encountered when Rack2Pro directory was not copied to a location plugins expected. I write about this here: VCV Rack plugin not showing in Bitwig - #13 by tobblestop