In my sessions, I use lots of regions. And as soon as I reach a somewhat high level of complexity, I would say it gets almost impossible to continue working because of the bad performance. On every zoom/move event, Ardour freezes for about a second or two, and for more complex operations such as multi-region copying the freezes take much longer. It’s very embarrassing when I want to show off my sessions and the beauty of open source to others.
I’ve always had these issues and currently work with latest A3 svn, but this applies to A2 as well and on both of my systems:
Workstation:
Intel Core 2 Duo 3 GHz, 5 GB RAM, ATI Radeon HD4850
Current video driver in use: fglrx_pci
Ubuntu DreamStudio 12.04 x64
Currently run latest Catalyst video driver, but I’ve tried the OSS one as well. No difference.
Ubuntu 11.10 x64
I can choose to run Ardour using either of the GPU:s with Bumblebee, but there is no difference using the Intel or Nvidia card.
I can’t see anything wrong with my systems and I haven’t really experienced this with other applications. But apparently not everyone have these issues, which leaves me still thinking there’s still something wrong with my system. I file it as these bugs:
unfortunately yes, this is a problem. I’ve learned to strip down my sessions every now and then (mainly removing regions and takes), but well… Ardour 3 feels better in my experience (self compiled with ‘waf configure --optimize’) but is still not very good for large sessions.
We have been looking at this on IRC a bit. It appears to be very system dependent. I have been sent sessions that are problematic for users, and they have no issues on any kind of my local systems. The problems appear likely to be graphics-related, but we do not currently know more.
is there anything I / we could do to help figuring this out? It seems that it happens both with Nvidia and AMD chips and also with open source and proprietary drivers. Also on different distros (at least different Debian based distros).
If we can help on IRC or mantis or somewhere just give us a call. A post-3.0 fix would be awesome!
I’ve experienced similar issues myself. I find that after working in most sessions for a while my zoom and move become slow. I work around it by saving, quitting mixbus, and then relaunching and it performs normally again. Fortunately it only takes about 5 seconds to quit and reload the session, but the gradual decline in performance as I work is the main problem. Not sure if this is completely related to the OP’s issue here as it sounds like the performance issues only ever get worse in that case.
In my experience the DE can have grave effects on both performance and look. I recommend to run one of the problematic sessions in a DE that does not do anything regarding themeing/FX in the background. Such as Fluxbox …
I’m working with Fluxbox and have this issue, so theming and FX are ruled out. I can also disable hardware acceleration in my xorg.conf, no difference. I’m working with the latest kernel and the indluded ATI OSS driver.
Mixbus will consumer more resources depending on your track/bus count as it has an EQ and compressor on every track, along with a few other things, but that is very high for a 16 track session IIRC.
I usually record large sessions, 8 tracks for about 1 hour, but mixbus doesnt seem to have much problem with that, a little slow on the zoom i guess but that seems normal to me taking into account the amount ot waves to draw…
Now i have a session of about 30 minutes with 16 tracks, most of them edited, fades, crossfades, any amount of regions…etc. and it also works “ok” considering all the information to show on screen specially when tracks are not minimized, what i don’t understand is if it is OK that these type of sessions consume around 50% DSP being idle, seems like too much having Jack set to 1024 frames on my system wich i think is pretty much fast (Phenom II x4 3.2Ghz, 8GB Ram @1600Mhz, RME 9652 interface and a Radeon HD 6870 video card)
would be nice to know if that behaviour is supposed to be allright or not…