View Issue Details

IDProjectCategoryView StatusLast Update
0002982ardourbugspublic2023-07-23 21:57
Reporterrealhangman Assigned To 
Status acknowledgedResolutionopen 
Product Version2.8.4 
Target Version3.0 
Summary0002982: performance issue with lots of regions (bad scalability)
DescriptionArdour gets painfully slow when the project has lots of regions.
I edit one mono track splitting one .wav file into about 80 regions and move them around, and the gui (e.g. when scrolling horizontally) gets very slow. This happens on an AMD Phenom 4 x 2,5GHz and 4GB Ram.

The behaviour can be improved by reducing the undo history (ah, there I also see that Ardour does not save the number of saved undos between sessioon loads), but this only improves the situation temporarily until you have to handle some more regions.

I would love to see Ardour being more scalable, as I often work with 10+ tracks for drum editing, where I have several hundreds of regions to work with.

Not sure if this is related to report 0002905
TagsNo tags attached.

  Users sponsoring this issue
Sponsors List Total Sponsorship = US$ 140

2010-01-01 18:44: realhangman (US$ 100)
2012-01-11 12:26: farbro (US$ 40)
  Users sponsoring this issue (Total Sponsorship = US$ 140)


has duplicate 0007685 new Cutting (splitting) regions too slow 



2010-05-27 20:55

reporter   ~0008082

For what its worth I find this to be quite an issue as well with a similarly specified PC as realhangman.


2010-05-27 21:30

administrator   ~0008084

this has already been addressed in ardour3. the entire undo/redo mechanism has been reimplemented for everything except automation data, which is much more compact than region state.


2011-04-12 16:20

reporter   ~0010549

Hi, an update: This has nothing to do with undo/redo. True, undo/redo gets very slow in A2 in a big session, this has been adressed in A3.

But my problem is the following scenario:

In a recent project (with A2 rev 9332), I have hundreds of regions and reduced the undo history to 7 and have no saved undo region at all (this gets saved now). Immediately after reopening the project, the gui (zooming, scrolling etc.) is very very slow. On top of that, Ardour crashes often while editing (splitting, trimming).

If I consolidate most of the regions, A2 is fast again, so it really is an issue with lots of (overlapping ?) regions.

I'd like to upload the project, but it's 20 GB big...


2011-04-12 16:30

reporter   ~0010550

Fwiw, I attach a zip file containing two session files.

The first file (2011-04-12T13:21:50.ardour) contains my slow session with hundreds of overlapping regions in the project.
The second (A2mainsession.ardour) contains the session with consolidated regions, i.e. no regions are deleted from the project but most have been removed from the timeline. A2 is quite fast here. This file contains some more data as it contains 2 more recorded songs.

Don't know if this is useful, tell me if you need something more.

2011-04-12 16:31 (359,277 bytes)


2011-04-14 22:03

reporter   ~0010554

Here we go with a video & detailed description how to reproduce this fast.


This is what I do:

1. Open a new project and import a file (this is a .flac file with about 5 minutes length)

--> Zooming and scrolling is fast

2. Split the region and copy one region over the other (Ctrl-left mouse and drag) some times (maybe 10-20) so we end up with quite some regions and crossfades.

--> Zooming and scrolling is already lagging

3. Do it some more

--> In this example, Ardour freezes for some time and is afterwards really slow. I never experienced this freeze and 100% CPU consumption before, but zooming and scrolling is painfully slow now.

4. Delete the regions

--> A2 is performing nicely again.

Conclusion: The undo/redo mechanism seems not to be the problem here. The problem is caused by too many overlapping regions, maybe also the underlying created crossfades. I have the feeling that it's better if you deactivate "create crossfades" beforehand, but it's not really that much better.
I know this is not a real world example, but imaging you have 14 tracks for drums and then cut and overlap some takes etc. You'll reach the limit very soon.


2011-04-14 22:31

developer   ~0010555

maybe this is a flac issue. can you try the same thing with a wav file ?


2011-04-15 07:58

reporter   ~0010560

Thanks for replying. Unfortunately, the behaviour is completely the same with a 16 bit wav file. You can also record a short region and then follow the same procedure as described above.


2011-04-15 12:16

reporter   ~0010561

Have you tried to open this session on A3. I would be interested to see if there is any noticeable difference in performance.


2011-04-18 21:32

reporter   ~0010582

A3 feels very slightly better, but has the same problem.
I realized something else, though: Ardour only slows down as long as it displays the regions. If you are scrolling hoizontally to another part of the project with little or no regions, the gui behaves normal. The vertical zoom level of the track is also important, i.e. the smaller the track height the better the performance.


2011-12-12 23:27

reporter   ~0012396

I confirm this issue on latest SVN. I do this kind of songs when I end up with lots and lots of short regions with samples. When reaching a somewhat large number of regions, the GUI starts performing extremely slow, especially copying/moving multiple regions completely locks up the computer and you have to leave it for up to 5 minutes before it's done processing the copying and you can start working again (though still with bad performance in scrolling etc).


2012-01-10 23:54

reporter   ~0012542

I would like to confirm this issue as well, at least for the ardour2 series.
Could this be due to the calculation or rendering of the waveforms?


2012-03-20 11:22

reporter   ~0012990

A quick note: I also experience the problem of slow scrolling within Audacity. When I have long file (about 30 Minutes) and zoom to near-sample level, horizontal scrolling becomes sluggish. I don't know if it's related, a shared library comes to my mind, but it also might be a coincidence.


2012-04-24 12:58

reporter   ~0013178

I have now been running Ardour SVN on my laptop since January and I must say that I do no longer experience these performance issues. It is still a bit slow but much better than on my stationary computer.

My laptop has an Intel Core i5 2410M and 4GB RAM and is running Ubuntu 11.10. The stationary has an Intel Core 2 Duo E8400 and 4 GB RAM on 11.04.

Any clue of what is causing the problem?


2012-06-14 10:15

administrator   ~0013530

Are we thinking that A3 is ok in this regard now?


2012-06-14 12:21

reporter   ~0013532

After further testing on both computers, I must now withdraw my last post. I haven't really experienced this problem with my laptop on my new projects, probably because they haven't been that complex. But now when I open up my old sessions on both of the computers, it performs just as bad on both.

This is my procedure to reproduce it:

1. Import a short half beat sample to say 5 tracks.
2. Duplicate them 20 times. Select them all and duplicate them, it goes pretty smooth.
3. Now, undo and duplicate the regions to a length of 100, this takes a moment but not too long.
4. Try duplicating all of them again, this will take a while and my Ubuntu freezes until it's done.

5. Delete all regions except the first ones. Do step 2 again, but this time the duplication will take *much* longer than the first time.

Apparently the bad performance starts when you reach a great amount of regions, and does not go away simply because you delete them.

This is on SVN 12717


2012-06-17 21:06

reporter   ~0013563

A3 rev.12747 is much better than A2 here! It still becomes slower with lots of overlapping regions, but I think it's much better. I still need to do some tests, though. I will report back.


2012-06-18 16:58

administrator   ~0013567

Should be quicker in SVN 12753.


2012-06-18 17:57

reporter   ~0013569

Can't see any difference here... :/


2012-06-18 18:18

administrator   ~0013570

What are you testing? I meant the duplicating regions test.


2012-06-18 19:04

reporter   ~0013572

Last edited: 2012-06-18 19:05

The duplications run fine here with A3 12756.

The performance with lots of regions though.. it's better and I don't expect a program to run perfectly smooth when stuffed with thousands of objects, but you can already feel this sluggishness after duplicating 5 regions 20 times, and after duplicating them a hundred times ( =500 regions), you'll see it for sure.

Again, this seems like a high region count, but when recording drums or whole bands with 10-20 tracks at once, you can't have too many takes before things will get slow.


2012-06-18 23:06

administrator   ~0013574

Is this sluggishness in moving around the session?


2012-06-19 10:30

reporter   ~0013593

Yes, when moving and zooming. Or when dragging a lot of regions, single regions are fine.


2015-02-06 12:41

reporter   ~0016326

How is this with current git or the nightlies?
Things that have improved scalability since 2012-16:
Canvas rewrite.
Caching of waveviews per source (helps with many regions from one audio source).
Improved waveview drawing speed.
Canvas doesn't update offscreen items.
There are probably many more, but it would be great to get an update on this.


2015-02-19 00:17

developer   ~0016355

Several regions "overlaid" as layers on the same track will slow down rendering of the red playhead dramatically.

Switching to "stacked" layer view will improve rendering (measured by how smooth the playhead moves) ... but it's still much worse than a single region on the track.

This is NOT panning or zooming the canvas ... just passing the playhead across the regions. After the playhead gets past the stacked regions, the playhead speed/smoothness will improve.


2015-02-19 00:36

administrator   ~0016356

behaviour isolated as slow drawing of waveform lines. fixes to come from two directions:

(1) direct, non-cairo rendering of waveform lines
(2) threaded rendering of image cache for waveviews


2015-03-12 22:13

reporter   ~0016421

I don't understand Paul's response, but in response to nick_m: To my understanding, the cairocanvas branch improves things, but it depends on your hardware and 2d acceleration driver support. Unfortunately I lack the time to test this more atm. I will certainly do some tests with the 4.0 release that's ahead.
Thanks for caring about the issue, Paul & co :)


2015-05-26 15:39

reporter   ~0016734

I've discovered that you can only really get reasonable performance when cairo can render to a gl backend.
By default, my radeon card doesn't do this, so i made a file

and put this in it:

Section "Module"
    Load "dri2"
    Load "glamoregl"

Section "Device"
        Option "AccelMethod" "glamor"
    Identifier "Card0"
    Driver "radeon"
    BusID "PCI:1:0:0"

The usual warnings about messing with this stuff appy: you may end up with a garbled display or worse if you try this out without knowing how to get back to your original state

Anyway, with only that in the file, things have sped up dramatically. I've been using it for months now without any problems.

lspci shows it to be:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]


2015-05-27 11:15

reporter   ~0016736

Apparently i've confused some people with that last note.
To be clearer, afaict the only way to get cairo to use hardware acceleration is by choosing an acceleration method which translates X requests into gl primitives.
In the case of Radeon cards, this means to use glamor.
This has nothing to do with the actual libraries used by the application. I am talking hardware acceleration at the video card driver level and nothing else.


2023-06-10 14:43

reporter   ~0027734


I'm using Ardour 6.9.0 (from KDE neon / Ubuntu 22.04) on an AMD Ryzen 1700 and I also observed this performance issue.
I think the easiest way to reproduce is to do the following:
- start with an empty project
- add two mono wave tracks
- record some silence on one track (or just import an arbitrary wave file, doesn't really matter)
- arbitrarily split up the wave into regions and optionally select + Ctrl-click to copy them in order to get at least 200 regions in total
Then, on my system I can observe the following numbers:
- when moving only few regions to the other wave track, the performance is fine
- when moving 100 regions to the other wave track, it takes about 6 seconds. During that time, the UI is kind of frozen and CPU usage goes up.
- when moving 200 regions, it takes over 30 seconds.

So, whatever Ardour does while moving these regions, something happens that obviously doesn't scale up well with the amount of regions.

Thanks and regards.


2023-07-23 21:57

reporter   ~0027907

Here's a summary of my findings on this issue. Also discussed this on Unfa #ardour chat channel with Paul and others.

I have been experiencing intermittent GUI freezes (Ardour doesn't respond to keyboard/mouse input) when the number of regions in the session file increase. From a certain moment certain edit operations become slow (5-10 seconds GUI freeze after each split region, move region, ...) and also stopping recording can take up to minutes before the recording is actually stopped. Strangely during the freeze I don't see CPU power go higher than 15%.

Paul says "apparently we still have some cases of O(N^x) where x>2 (N is the number of regions". x42 confirms "so far I have only been able to establish that it is a GUI issue. a headless Lua script splitting regions runs fast."

For me specifically in 2023 on a fairly fast computer this means: fast response time with up to 1000 total number of regions in the session file. When having 2000+ regions in the session the intermittent freeze builds up to around 3-4 seconds. When going to 4000+ regions this freezes for at least several minutes. It doesn't make any difference if the regions are all referring to the same underlying audio file or to different (parts of different) audio files. Also the regions can be on the same or on different tracks.

As a workaround:
- the following do NOT work:
    * muting or deactivating the track containing lots of regions
    * muting the regions (Edit selected regions > Gain > Mute)
- these DO work:
    * Combining lots of regions (Edit selected regions > Edit > Combine)
    * Putting the separate regions on a playlist of the track that is not active/selected
    * Removing the regions from the session (via automatic cleanup or manually)

Combining related regions is the most elegant workaround, since you can easily uncombine afterwards in case you need to do some more edits afterwards.

This ticket is 13 years old, but still an issue.

I propose to close the following two tickets, which I'm quite sure they are duplicates:

Issue History

Date Modified Username Field Change
2010-01-01 18:44 realhangman New Issue
2010-01-01 18:44 realhangman Sponsorship Added realhangman: US$ 50
2010-01-01 18:44 realhangman Sponsorship Total 0 => 50
2010-04-24 10:28 cth103 Category bugs => bugs2
2010-04-24 10:30 cth103 Category bugs2 => bugs
2010-05-27 20:55 confusion_music Note Added: 0008082
2010-05-27 21:30 paul Note Added: 0008084
2011-04-12 16:20 realhangman Note Added: 0010549
2011-04-12 16:30 realhangman Note Added: 0010550
2011-04-12 16:31 realhangman File Added:
2011-04-14 21:05 realhangman Sponsorship Updated realhangman: US$ 100
2011-04-14 21:05 realhangman Sponsorship Total 50 => 100
2011-04-14 22:03 realhangman Note Added: 0010554
2011-04-14 22:31 oofus Note Added: 0010555
2011-04-15 07:58 realhangman Note Added: 0010560
2011-04-15 12:16 lincoln Note Added: 0010561
2011-04-18 21:32 realhangman Note Added: 0010582
2011-12-12 23:27 farbro Note Added: 0012396
2012-01-10 23:54 lievenmoors Note Added: 0012542
2012-01-11 12:26 farbro Sponsorship Added farbro: US$ 40
2012-01-11 12:26 farbro Sponsorship Total 100 => 140
2012-03-20 11:22 realhangman Note Added: 0012990
2012-04-24 12:58 farbro Note Added: 0013178
2012-04-25 14:33 cth103 cost => 0.00
2012-04-25 14:33 cth103 Target Version => 3.0
2012-06-14 10:15 cth103 Note Added: 0013530
2012-06-14 10:15 cth103 Status new => feedback
2012-06-14 12:21 farbro Note Added: 0013532
2012-06-14 23:33 cth103 Severity major => block
2012-06-14 23:33 cth103 Status feedback => acknowledged
2012-06-17 21:06 realhangman Note Added: 0013563
2012-06-18 16:58 cth103 Note Added: 0013567
2012-06-18 17:57 farbro Note Added: 0013569
2012-06-18 18:18 cth103 Note Added: 0013570
2012-06-18 19:04 realhangman Note Added: 0013572
2012-06-18 19:05 realhangman Note Edited: 0013572
2012-06-18 23:06 cth103 Note Added: 0013574
2012-06-19 10:30 realhangman Note Added: 0013593
2015-02-06 12:41 nick_m Note Added: 0016326
2015-02-19 00:17 BenLoftis Note Added: 0016355
2015-02-19 00:36 paul Note Added: 0016356
2015-03-12 22:13 realhangman Note Added: 0016421
2015-05-26 15:39 nick_m Note Added: 0016734
2015-05-27 11:15 nick_m Note Added: 0016736
2018-11-10 18:29 x42 Relationship added has duplicate 0007685
2023-06-10 14:43 slash42 Note Added: 0027734
2023-07-23 21:57 Krio Note Added: 0027907