Ardour 8.0 Slowing Down Computer

Getting Stuff Done How do I .... ?
#1

I’ve just updated to 8.0. (Thanks to all developers! The list of new features is quite appealing!)

In my current project (which is not very large), Ardour started to get slow and slowing down the whole computer. (Comparable sessions ran just fine with versions 7.5 and earlier.) It was working just fine for a while, but it then started to slow down. I would press play (space bar) and have to wait a couple of seconds to start playing. Even adding the ACE Amplifier plugin to track would take a few seconds. I noticed that the DSP was not too high, so I don’t think it was the problem.

I tried to reboot the computer to see if it would fix. It took over 2 minutes for Ardour to just quit. (It was using over 84% of the 32GB of memory of the system.) But, the problem persisted after the reboot. (Again, even quitting took a couple of minutes.)

Note that I was running some Windows plugins (IK multimedia) with yabridge, but it never caused anything like this before. I have not updated yabridge or wine recently.

I am running Debian Sid with a Focusrite 2i2 (2nd gen). Now, the computer is old (Intel Core i7-4771, 32GB of memory, Radeon HD 7750):

$ inxi -v3
System:
  Host: debian Kernel: 6.5.0-6.slh.1-aptosid-amd64 arch: x86_64 bits: 64 compiler: gcc v: 13.2.0
    Console: pty pts/24 Distro: aptosid 2013-01 - kde-full - (201305050307) base: Debian GNU/Linux
    trixie/sid
Machine:
  Type: Desktop System: ASUS product: All Series v: N/A serial: <superuser required>
  Mobo: ASUSTeK model: Z87-PRO v: Rev 1.xx serial: <superuser required>
    UEFI: American Megatrends v: 2103 date: 08/18/2014
CPU:
  Info: quad core model: Intel Core i7-4771 bits: 64 type: MT MCP arch: Haswell rev: 3 cache:
    L1: 256 KiB L2: 1024 KiB L3: 8 MiB
  Speed (MHz): avg: 3753 high: 3789 min/max: 800/3900 cores: 1: 3789 2: 3756 3: 3698 4: 3752
    5: 3738 6: 3759 7: 3758 8: 3774 bogomips: 55970
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: AMD Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] vendor: VISIONTEK driver: amdgpu
    v: kernel arch: GCN-1 bus-ID: 01:00.0 temp: 47.0 C
  Device-2: Logitech Webcam C270 driver: snd-usb-audio,uvcvideo type: USB bus-ID: 3-6:5
  Display: server: X.org v: 1.21.1.8 with: Xwayland v: 23.2.1 driver: X: loaded: amdgpu
    dri: radeonsi gpu: amdgpu tty: 156x74 resolution: 1: 1920x1080 2: 1920x1080
  API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast platforms: active: gbm,surfaceless,device
    inactive: wayland,x11
Network:
  Device-1: Intel Ethernet I217-V vendor: ASUSTeK driver: e1000e v: kernel port: f040
    bus-ID: 00:19.0
  IF: eth0 state: up speed: 100 Mbps duplex: full mac: e0:3f:49:a3:4c:a6
Drives:
  Local Storage: total: 13.88 TiB used: 7.27 TiB (52.4%)
Info:
  Processes: 398 Uptime: 7h 54m Memory: total: 32 GiB available: 31.3 GiB used: 8.92 GiB (28.5%)
  Init: systemd target: graphical (5) Compilers: gcc: 13.2.0 Packages: 7637 Shell: Bash v: 5.2.15
  inxi: 3.3.30

Is it just too old to handle it? If not, would running GDB help finding what is slowing it down? Any suggestions on what to do to find the problem? (I’d be glad to file a bug report, if that is the case. I am just not sure if it is something on my end.)

#2

Defiinitely not the problem… I’m using Ardour 8 on much older and slower hardware with only 8Gb of RAM…

Did you upgrade the Kernel recently? 6.5 still has pretty wet paint… I rarely upgrade a working Kernel on my Studio box, only if there is a known security vulnerability…

#3

Thanks, Glen! That’s good to know.

No, I’ve been using 6.5 for a while, but today I even tried an older kernel, with the same results…

It really seems to be a memory problem. When I start Ardour (with my current project), the memory usage is reasonable and everything works fine. (Except, horizontal scrolling, which is not very smooth. I think it was smoother before…)

Ardour2
Ardour21000×1120 407 KB

After working on it for a while (this time, mainly working on automation), the memory usage shoots up:

Ardour
Ardour984×1102 235 KB

The DSP stays at around 50% through out.

EDIT: FWIW, I did not seem to have this problem with version 8.0.rc3.9.

Any suggestions would be appreciated.

#4

Hi again,

Hmm that does look like something is leaking memory, I should clarify my comments were mostly based on the 8 RC’s and I have only done a couple of quick mixes with the actual Ardour 8 release… I have people coming in for a session this evening so I will keep an eye on the memory usage and post back if there is a similar pattern appearing.

#5

EDIT: I changed my post, your on linux, not windows.

Have you tried safe mode ?

Rescan all.plug ins ?

What audio drivers are you using ? ALSA, JACK, Pipewire ?

Wayland or X11 ?

#6

Thanks @Schmitty2005 and @GMaq for your help!

Thanks! I really appreciate it.

I must say I’ve only worked in this one project with version 8.0, so maybe there is something wrong with this particular session.

No, I have not tried those… Safe mode will disable my plugins and not allow me to work. But I can try to rescan.

ALSA.

X11.

#7

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).

#8

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
#9

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.

#10

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

#11

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
#12

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 ?

#13

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:

auto1
auto11960×1088 258 KB

auto2
auto21960×1088 289 KB

auto3
auto31960×1088 300 KB

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…

#14

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.

#15

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.

#16

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!

#17

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.

#18

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.

image
image723×722 68.6 KB

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

#19

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%.)

#20

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