View Issue Details

IDCategoryLast Update
0002982bugs2018-11-10 18:29
ReporterrealhangmanAssigned To 
Status acknowledgedResolutionopen 
Product Version2.8.4 
Fixed in Version 
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.

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