Ardour 8.0 Slowing Down Computer

Yeah, except I have just done a basic check and cannot reproduce this. Either the session I use does not trigger this or this there is something system-specific that causes this.

A few years ago there was some report that when using multiple displays with nvidia graphics leaks in the graphic driver, but that was only one person on IRC

It was not a user-space leak. pmap showed ever increasing memory areas mapped to the graphics card. We tracked that down with

pmap -x `pidof ardour`

but found no solution. Perhaps something similar happens here with XWayland and AMD?


Can others here try?

Start Ardour, then in a terminal Window run htop. The “RES” ident memory of Ardour should stabilize after a while. It will increase initially (waveform cache) and there will be occasional spikes when locating (reading data from disk).

htop RES was stable on Ardour 8 release downloaded from here. Stable on X11 and Wayland. Audio / MIDI and very few plug ins. Intel Laptop video.

1 Like

But, if you run in safe mode and the problem goes away, you know it is plug-in related, and not Ardour causing the issue. You won’t be able to work but a big piece of the puzzle may be solved. Or is it a MIDI only session with virtual instruments ?

What sampling rate are you using ?

If rescan did not help, if this was my system, I would try these two things :

  1. Are you able to boot into Wayland ? @42 pointed out it may be some sort of graphics card issue. Maybe using Wayland instead of X11 resolves it ?

  2. I would try an older kernel. As @GMaq was saying, it is pretty new and may not work well with your specific setup. The linux boot menu on your system may allow you to select a previously installed kernel temporarily for trial.

Yes! Thanks for suggesting that. That might indeed be the most obvious.

Checking back after my session tonight, unfortunately (or I suppose fortunately) I could not reproduce any memory leak issues and I was running Ardour 8.0.0 with 20 track sessions with a a fair number of both native Linux and bridged Plugins… My Studio Box still runs Debian 11 and a pre 6.X Kernel with Enlightenment on Xorg so a very different set of variables than Luis is working with…

1 Like

What specific automation parameter are you working on ? Audio or MIDI ? Track, Buss, or Master ?

Are you using the freehand automation editing ? How many different automation points do the lanes have ?

Could you post a screenshot of showing the automations ?

Indeed, I did not see the problem in Safe Mode…

I also tried a different session (much smaller) and had no problems.

48 kHz.

Same problem with Wayland.

It tried Debian 6.5.3-1 RT kernel, and had the same problem.

I was adding automation to the ACE Amplifier plugin (adjusting the volume at certain parts) for multiple instruments. Some were audio tracks, some were audio buses. I only have two very simple MIDI tracks for triggered kick and snare. But they are disabled now, since I printed the audio.

I am creating edit point with the edit/draw tool and adjusting. Nothing too crazy, and with very few added points. I think I have about 8 automation lanes.

Here are some:



I can’t say for sure, but it does seem related to video. Rendering in the session gets very slow. Redrawing the screen when following the playhead is very choppy…

And, even after Ardour is closed and the memory usage goes down, I seem to still have some “choking” in the desktop (KDE Plasma), for instance changing desktops, maximizing windows, etc.

I will try in some other sessions that are more complex that the alternative ones I tried so far and see what happens…

FWIW: On another session, which is still in the middle of MIDI programming and recording, so fewer plugins (except for instruments, which were mostly disabled during my test), I noticed the memory increase, but very little…

It stated with about 31GB 31% of memory (I have a couple of instances of DrumGizmo on this session) and in about half an hour it increase to only a little over 32GB 32%. I think this is a slower rate than my current project.

How much physical memory in the computer? Nevermind 32gb from your previous post.

Solid state hard drive or 5400/7200 rpm drive ?

Your computer may just be writing and reading from the swap file causing a major bottleneck.

Also, the Drum gizmo drums from the website are 44.1kHz. Drum gizmo may be using more memory to upsample them to 48khz. I am not certain though.

Maybe disable only the drum gizmo plugin and see what happens to the memory usage.

I also noticed that 8.0.0 seems to run a bit slower, with lags between issuing a command and it being executed (e.g pressing play/record). I think there may be a graphics issue, as for instance, when I do a remove previous capture, the edit screen does not change after the dialog box slowly closes.
I’m using AVL21.3 on a 2017 thinkstation with 32Gb ram and nvidia graphics.
I havent tried to diagnose it yet, just adding my observations.
Still, I’m finding it more stable that any V7 versions, which is great!

First, in my post above I meant 31% (of my total 32GB of memory), not 31GB of memory! Sorry…

The session is in a Samsung SSD 860 (1TB).

The CrocellKit is 48 kHz. As I said, I am not 100% sure the increase in memory was due the possible leak, as it took a about half an hour to increase 1%. In my current project, in about the same time it went from 5% to 75%. Possibly due to the many plugins in this one…

I will run it in Safe Mode again and observe the memory usage over a longer period and see if there is any increase.

What about possibly opening the session in question, and slowly deleting specific plug-ins while watching the memory in HTOP ? Just make sure not to save the session after you deleted the plug ins. Do any of the plug ins seem to have a fancy GUI ? If this was my system, I may check into the video drivers. I did have a problem at one time related to OpenGL / Mesa being configured to use an older version on the system. I am sure a google search would find out how to check. On my Ubuntu it is :

glxinfo | grep “OpenGL version”

I Tried Drum Gizmo on my system. 3 instances of Drum Gizmo with Crocell, DSR, and Muldjord. LV2 and VST3. Memory only increased by about 1GB with each instance. What is your DrumGizmo Disk Streaming Cache Limit set to ? I assume you left it at default though.

It would be nice if you could find out what is causing this.

I’ve done some further testing.

I’ve taken out some of the plugins, to see if would still happen. My main suspicion was those running under wine, so I removed them. They were TR5 Comprexxor, De-Esser, and Fame Studio Reverb.

And it seems that memory still increases, although it seems to be slower. The session, after a few minutes, used about 5% of the memory, and after 15-20 minutes it reaches 6.7%, and continues to increase.

It also seems that visual actions, like zooming in and enlarging tracks, speeds up the memory increase. So, when actually editing (like I was adding automation before), where this is done more often, the memory would increase faster then when just mixing.

I don’t think so. What remains are some LSP, x42, ACE, u-he (Presswerk, Colour Copy, and Satin), TAP Tubewarmth, Dragonfly Reverb, GVST GChorus, FirComp2, and Instinct Saturation.

Since I have (or had?) plenty of memory, I had no disk cache, the kits were loaded in memory. (That’s why it started with 31%.) But, FWIW, this is another session (not the current one), I only tested once. These more recent tests were done with my current session, with no DrumGizmo.

I have:

 $ glxinfo | grep "OpenGL version"
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.2.1-1

$ apt policy mesa-common-dev 
mesa-common-dev:
  Installed: 23.2.1-1
  Candidate: 23.2.1-1
  Version table:
 *** 23.2.1-1 500
        500 http://debian-archive.trafficmanager.net/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

$ apt policy xserver-xorg-video-amdgpu
xserver-xorg-video-amdgpu:
  Installed: 23.0.0-1
  Candidate: 23.0.0-1
  Version table:
 *** 23.0.0-1 500
        500 http://debian-archive.trafficmanager.net/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

$ apt policy firmware-amd-graphics
firmware-amd-graphics:
  Installed: 20230515-3
  Candidate: 20230515-3
  Version table:
 *** 20230515-3 500
        500 http://debian-archive.trafficmanager.net/debian unstable/non-free-firmware amd64 Packages
        500 http://debian-archive.trafficmanager.net/debian unstable/non-free-firmware i386 Packages
        100 /var/lib/dpkg/status

$ apt policy libdrm-amdgpu1
libdrm-amdgpu1:
  Installed: 2.4.115-1
  Candidate: 2.4.115-1
  Version table:
 *** 2.4.115-1 500
        500 http://debian-archive.trafficmanager.net/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

But I am not sure how to find if there is any compatibility issues.

Indeed. I guess I could live with it, by restarting the session when it starts to slow down, but it is not ideal.

(And after another 10 more minutes, so 25-30 minutes into the session, looping the project, memory has reached 10.3%.)

I had the same problem and could trace it back to instinct. Since then I no longer use the plugin (although it sounds good to my ears). Unfortunately, I have not yet taken the time to write to the manufacturer.

2 Likes

That will eventually settle. You can configure the Waveform cache size in Preferences > Performance (default is 100MB).

Ah, that’s very interesting! It was the next one I was going to remove and try, since I don’t use it often. I will test it tomorrow morning. Thank you very much for pointing it out!

I will also test that. It seems it was more than that, since usage would go from 5% to 10% (and the difference is 5% of 32GB = 1.6GB), which seems a bit too much. I will try some it some more, but hopefully the whole problem is just the Instinct plugin.

OK, confirmed. It was indeed Instinct causing the memory leak.

I will contact the company and see if they are willing to investigate. Many thanks to @synthesis for cracking this one. It is a huge relief to me!

And thanks to @Schmitty2005, @GMaq, and @x42 for the help!

I will let everyone know if I rear back from them in the near future.

3 Likes

Someone from Inertia Sounds System replied to my message saying that they are working on version 1.1 of Instinct, and that they have squashed some bugs and made improvements. They said that I should contact them if the problem persists with the new version (when it comes out).

We will see how it will turn out, but they seemed genuinely interested in addressing the issue, and it is nice to see such a quick response.

4 Likes

Thank you for taking the initiative.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.