View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002982 | ardour | bugs | public | 2010-01-01 18:44 | 2023-07-23 21:57 |
| Reporter | realhangman | Assigned To | |||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Product Version | 2.8.4 | ||||
| Target Version | 3.0 | ||||
| Summary | 0002982: performance issue with lots of regions (bad scalability) | ||||
| Description | Ardour gets painfully slow when the project has lots of regions. Scenario: 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 http://tracker.ardour.org/view.php?id=2905 | ||||
| Tags | No 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) |
|
|---|---|---|
| has duplicate | 0007685 | new | Cutting (splitting) regions too slow |
|
|
For what its worth I find this to be quite an issue as well with a similarly specified PC as realhangman. |
|
|
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. |
|
|
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... |
|
|
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
|
|
|
|
Here we go with a video & detailed description how to reproduce this fast. Link: http://www.septimbears.de/a2-performance.ogv 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. |
|
|
maybe this is a flac issue. can you try the same thing with a wav file ? |
|
|
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. |
|
|
Have you tried to open this session on A3. I would be interested to see if there is any noticeable difference in performance. |
|
|
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. |
|
|
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). |
|
|
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? |
|
|
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. |
|
|
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? |
|
|
Are we thinking that A3 is ok in this regard now? |
|
|
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 |
|
|
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. |
|
|
Should be quicker in SVN 12753. |
|
|
Can't see any difference here... :/ |
|
|
What are you testing? I meant the duplicating regions test. |
|
|
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. |
|
|
Is this sluggishness in moving around the session? |
|
|
Yes, when moving and zooming. Or when dragging a lot of regions, single regions are fine. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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 :) |
|
|
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 /etc/X11/xorg.conf.d/50-radeon.conf and put this in it: Section "Module" Load "dri2" Load "glamoregl" EndSection Section "Device" Option "AccelMethod" "glamor" Identifier "Card0" Driver "radeon" BusID "PCI:1:0:0" EndSection 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] |
|
|
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. |
|
|
Hi. 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. |
|
|
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: https://tracker.ardour.org/view.php?id=2905 https://tracker.ardour.org/view.php?id=7685 |
| 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: slow-project.zip | |
| 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 |
