AV Linux and MX Moksha 25 Released!

Same as Glen.
It works when executed from terminal,
but it doesn’t when added to lines in “bash.bashrc” file in “etc” folder.
I cannot make it permanent however i try :slight_smile: .
What am i missing?

And still, i’m i dreaming or vst2 1.2.1 variants felt lighter on processor than LV2 1.2.25 with Cairo taking over the drawing aspect?
With Cairo these more larger/busy plugins have problems when a few gui’s are on the screen. Maybe simultaneous drawing of a few RTA-s is resource demanding? They seem to stop/make difficult the drawing of Ardours own graphics?

That’s what i noticed while testing 1.2.25 LV2 with Cairo for about an hour.

EDIT: Hahahah i managed to make so that it opens up Ardour(with LSP Cairo) automaticaly whenever i just click to open the Terminal :slight_smile: :slight_smile: :slight_smile:

yea, i kinda fugured it out by falowing the path to ardour’s folder, looking at the version numbers, figuring out what’s the script for execution of Ardour, reading online where’s what in debian variants of linux etc etc…it took a while (about 2 hours) before i got those 2 lines correct…but hey :slight_smile:
hell, i might be a dumb windows user, but i used to programm in fkn Basic as a kid, turned my good old c64 inside-out :slight_smile: .

@Ljuba I admire your perseverance, most people would have given up long ago. It’s regrettable that your first AVL experience is with this particular unforeseen OpenGL problem, unfortunately I can’t reproduce the issue to give better advice because I’m down to 2 machines here and OpenGL is working on both…

Thank you for your patience!

1 Like

No worries Glen.
Look, it’s not my first AVL experience :slight_smile: . I used a couple of versions of AVL on and off, starting from maybe 7-8 years ago, maybe more, i don’t remember exactly when. Created bunch a of cue tracks / demos for the bands I was in at the time, using mostly Hydrogen+Big Mono Drum kit (I still think that’s a cool kit, and Hydrogen is sooo handy, or should i say cute :slight_smile: ). It was as if you have a shitty guitar which you really like to play.

First time i installed Ardour, I did it on some ancient Ubuntu 8.04 or something, manually downloading a bunch of dependencies from their respositories using net at my college, burned it all on a CD, and transfered that on my PC. That was maybe 2008-2009.
So, this is nothing new.

The new thing with my linux experience is - LSP plugins have some awesome features, like mid-side processing, sidechaining etc. It’s getting really good for mixing. That’s what I see, not only hick-ups.

1 Like

Here’s what i’ve found out, tinkering here and there:

1.) - USEFUL INFO FOR EVERYONE HAVING TROUBLE WITH OPENGL SUPPORT WHO WANTS TO USE LSP PLUGINS version 1.2.25 IN AVL 25:

There is a very simple way to make LSP permanently use Cairo, overriding OpenGL in AV Linux:

Log in as root.
Open the file called “enviroment”, path “/etc/”, using text editor.
(We could also describe that as - Open Thunar FIle Manager, click on File System under Devices, find and enter folder called “etc”, scroll down, find and open file called “enviroment”).
Copy-paste the forementioned line inside that file, literally just like LSP provider described:

LSP_WS_LIB_GLXSURFACE=off

Save that file. Log out.
Log in as user.

Now, whenever you open up Ardour and insert an LSP plugin, you’ll se in its GUI, in the tab “Menu” that it is automaticaly reverted back to Cairo, and not using OpenGL.
Tested that approach in practice, i’m using it right now on my own system.

2.) - INFO NOT REALY USEFUL(or maybe it is?), EXCEPT IF YOU’VE GOT THE SAME LAPTOP
(Fujitsu Lifebook E746, i5-6300U, Intel HD 520, 8GB ram)

For some reason, LSP version 1.2.25 VST2 variants with Cairo work best for me. LV2 and VST3 variants under Cairo choke Ardour’s own graphics. Even if i only pull up, say, 2 instances of LV2 GUI’s under Cairo - they block Ardour’s graphics. VST2 variants don’t behave like that. While testing, i pulled up 7-8 realy busy/demanding instances of LSP VST2 GUIs and everyhing in Ardour stayed normal. Only downside i see there is that if i pull many instances of LSP VST2’s under Cairo at the same time, RTA’s in LSP plugins become visibly slower, less responsive, little choppy, but the Ardour’s graphics, animations, interactivity (and sound playback) remain responsive, good, unaffected.

That’s it for now. I’m gonna stick to 1.2.25 VST2 variants with Cairo for now. Works for me.

1 Like

Just wanted to cross post, that I have a similar symptom in my Ubuntu Studio system. So this might not be an AVL issue.

1 Like

Today i’ve been digging around a bit. Turns out, i needed older kernel 5.10 and non-free software packages (firmware) for this particular laptop(Fujitsu Lifebook e746) to fully support OpenGL with this machine. So i tried Debian 11+KDE+Non-free unofficial iso, and it just works. Installed Ardour 8.12 + LSP 1.2.25 and OpenGL works, proc usage is normal, everything fine. So…No AVL for this particular machine :slight_smile: . I’m also gonna try AVL on my Lenovo Ideapad Gaming 3 (AMD Ryzen 5600H, RTX 3050, 16GB ram) in near future, to see how that goes…

1 Like

I use builtin AMD graphics and OpenGL works fine for me (Ryzen 4800H CPU). In most cases problems with graphics are related to bad OpenGL support.

1 Like

OpenGL may work even faster if I get rid of the multisampling which may be too heavy.
I recently created the issue on GitHub to avoid multisampling and implement edge smoothing algorithm in the fragment shader.

1 Like

I wastn’t having any peace and couldn’t keep steady :slight_smile: , so i pulled out ssd from fujitsu laptop e746 with Debian 13 KDE set to x11 and stick it into Desktop Dell Workstation 8th gen i7 8700 with Nvidia Quadro RTX4000 and 24GB of ram…

And, as i suspected, it all works as a charm.
Cpu usage is minimal, LSP GUI’s work on OpenGL and are very fast. Audio works good, all seems ok and stable.

Something’s up with those integrated intel HD GPU chips. I cannot graps what it is, but something definitely is :slight_smile: .
(What i didn’t try and i should cause it seem like a good test is to install and play some graphics intensive game under Linux with OpenGL rendering…Logic is - if it renders the game normaly, then it should also render LSP gui just fine, right?..)

@Ljuba

Just so I’m clear on this… On the various systems you’ve been testing has only AVL had this openGL problem or have other OS’ and/or DE’s shown the same issues on that particular hardware?

I have had a few reports on some systems with older Intel GPU’s about stability issues and problems but I can’t reproduce them even on a T490 Thinkpad with an Intel GPU.

1 Like

No, not only AV Linux - Debian 13, 12 and 11 too. I tough for a second that Debian 11 behaves normaly, but no, same problem. KDE+XFCE or Enlightment in AVL 25…no real difference. This is unrelated to OS or DE.

Problem is definitely caused by lower end Intel GPUs (HD520, HD630, HD2500) integrated in CPU i-series chips when combined with LSP plugins and OpenGL renderer.

And not only integrated GPUs. Unfortunately. I’m also testing Debian 13+LSP and low-end Asus GT610 1GB pcix graphics card, and the problem is the same. LSP+OpenGL is crashing Ardour, OpenGL+Cairo works with these low-end cards.

BUT…
…ON THE OTHER SIDE - i7 8th gen 8700 in combination with NVidia Quadro RTX4000 + LSP with OpenGL rocks! It’s realy fast, responsive, they feel great. Much better than Cairo.
That was also on Debian 13, KDE.

(P.S-Another thing i managed to conclude is that, for whatever reason, in combination with Cairo renderer, vst2/lxvst variants of LSP work best, are most responsive, feel lightest on CPU).

I will also going to try and see whats the AMD Ryzen 5600H +radeon igpu+Nvidia 3050+ LSP + OpenGL like…Maybe by installing OS on a external SSD so i don’t have to dismantle Lenovo Ideapad Gaming 3. We’ll see about that :slight_smile:
I’ll try AVL 25 Enlightment and Debian 13 KDE and see how it goes.

Happy New Year everyone!
(Let it be the one in which we optimize LSP with OpenGL :slight_smile: :slight_smile: :slight_smile: )

News. Found a few hours this morning. Installed AVL25 to external ssd (usb 3.0 connection)
Ran it on Ideapad Gaming 3 (5600H, AMD iGPU, NVidia 3050 dicrete GPU, 16GB Ram).
AVL 25 Works with iGPU, except LSP with OpenGL. They lock the Ardour when 4 LSP instances are pulled up on screen, and their GUI resizing is buggy.

Then i followed this info, and installed proprietary NVidia drivers, enabled Nvidia 3050 as a defualt renderer:

The situation is somewhat better, but still not perfect. LSP don’t lock Ardour now, but they do become sluggish and visably slow (analysers become useless) when more that 4 instances are pulled up on a screen.

That’s all with using Cables to set up the integrated audio card, Jack/Pipewire backend option in Ardour.
Audio playback seems unaffected by graphic rendering sluggishness. Audio playback is always fine.
The one option i still haven’t tried is to use external audio interface. All get back with that info.

Hello and Happy New Year!

Hmmm, a couple of things… First, with this machine do you have openGL compositing enabled in Enlightenment as described earlier in the thread? Also since AVL uses the MX ‘advanced hardware’ ahs Repo and it recently had a Mesa update I wonder if we’re bumping into the same LSP issue as the Arch users here with a bad version of Mesa…? Pure Debian 13 would still have the older version of Mesa and older LSP. An updated AVL has newer Mesa and latest LSP Plugins.

Are other Plugins and performance OK?

1 Like

I need to check that when i get the chance to tinker with laptop again, but…
As far i i remeber i checked the Enlightment’s compositor setting and it was set to OpenGL while it was still on AMD/Ati iGPU. Checked in the terminal output for GPU and it said that Ati was enabled/nvidia disabled, and the renderer was Ati, and Open GL engaged.
But, that wasn’t the winning combo in Ardour.

Then i installed NVidia proprietary drivers using instructions in that video above, loged out/loged in as root and added enviroment variables using commands described in that video description (to make MX use Nvidia as a default renderer), using AVL root account. Restarted. Log in as user.
Again checked in terminal output of gpu, and it surely said that it is using nvidia 3050 for rendering and OpenGL is active.
Tried that, got the described results.

OK, thanks for the info. To be clear there shouldn’t be any direct relationship between the Enlightenment compositor rendering settings and Ardour/LSP but I have had a few reports that the non-openGL software rendering can cause higher CPU usage and poorer Video playback etc… I would guess on older systems with no openGL support in the first place.

1 Like

Ok, more info. (Lenovo Ideapad Gaming 3, Rayzen 5600H+AMD/ATI Radeon iGPU + Nvidia GTX 3050 4GB + 16 GB Ram, AVL 25, installed Nvidia proprietary drivers).

OpenGL compositing in Enlightment is set up as Glen described before.
Other plugins except LSP work with no issues. I managed to run more than 20 of instances with GUIs of different plugins with no issues. LSP also work (with OpenGL), as long as it’s not more than 3 of LSP GUI’s open at the same time. If i pull up 4th, it locks Ardour up, and i have to kill Ardours process to continue.

Then i noticed something, using this command.

glxinfo | grep “OpenGL version”

It showed AMD/ATI. Renderer actualy reverted back to iGPU.

So, since it’s actualy iGPU, that behaviour actualy made sense, cause, this AMD/ATI iGPU is exactly that much better compared to Intel iGPU’s i tried earlier (2GB vs 1GB), so it took that much more pressure to get LSP to missbehave.

Then i tried to update BIOS so i could set discrete Nvidia 3050 GPU to be used constantly.
No luck there. Even the latest Bios offers only 2 options:
1.) to use only iGPU
or
2.) the GPU’s to be switchable. No constant use option for discrete GPU in BIOS.

I found out by googling that i could make specific apps use discrete GPU in MX Linux with these commands:

export __NV_PRIME_RENDER_OFFLOAD=1;
export __GLX_VENDOR_LIBRARY_NAME=nvidia

And sure thing, i could make “some” changes using that in terminal, cause, now if i run:

glxinfo | grep “OpenGL version”

I get:
OpenGL version string: 4.6.0 NVIDIA 555.5

Cool. But, i can’t find a way to be sure that Ardour actualy use the discrete GPU(and i suspect it dosen’t), cause, if i try to run Ardour from terminal, after changing directory to Ardour’s, and applying forementioned commands, when i try to run Ardour(like in that example below) i get:

ljuba@mx:/opt/ARDOUR-8/bin
$ ./ardour-8.12.0
./ardour-8.12.0: error while loading shared libraries: libardourcp.so: cannot open shared object file: No such file or directory

…and yes, the file is already set to be executable…owner is root.
Maybe it’s something about syntax in this case, i realy don’t know.
That’s where i’m stuck right now.
Ideas?

P.S. Question. If i manage to run Ardour on discrete GPU using this method, will LSP surely also be rendered using discrete GPU? Will LSP inherit those commands/settings?
And…subquestion :slight_smile: If i do the project on this machine, and then move it to another machine which has trouble supporting OpenGL, will that project be normaly editable with Cairo?

Hmm…by reading previous Vladimir’s comments about using enviroment variables directly from terminal i gather that i could maybe try:

export __NV_PRIME_RENDER_OFFLOAD=1;
export __GLX_VENDOR_LIBRARY_NAME=nvidia
…and then adding full ardour path right beneath those lines?

Syntaxwise, that could work, right?

Ok, the path to ardour wasn’t right earlier. Path to ardour is ok now (look at example below), it opens up, but it still isn’t using discrete Nvidia GPU. Instead, it still uses integrated AMD(something is wrong with those lines):

export NV_PRIME_RENDER_OFFLOAD=1
export GLX_VENDOR_LIBRARY_NAME=nvidia
/opt/ARDOUR-8/bin/ardour8

And, as i suspected, when you throw more demanding graphics tasks with more LSP instances (3 is max for it to stay normal, 4th locks up ardours responsivnes), amd usage jumps high, and ardour locks up. Look at NVTOP info from this screenshot:

P.S. Hey, i have an idea. Maybe those commands don’t work since i installed proprietary Nvidia drivers? I don’t know is that method related to foss and proprietay drivers, or only one of those possible situations…Does anybody have a clue?

Hi,

I think those commands would only work with proprietary nVidia drivers because they are what provide the ‘nvidia’ driver, otherwise it would be Xorg ‘nouveau’ driver by default… I still think the latest Mesa drivers in MX/AVL may possibly be a potential suspect here. I wonder if a pure Debian or MX Linux ‘non-ahs’ ISO would exhibit this issue as well? That said it does seem odd that you aren’t seeing any issues when using other multiple instances of other Plugins… I believe the reported issues here with Mesa on Arch were also with LSP at least in some cases…

1 Like