Hi there. I am running Ardour on Ubuntu 10.04 Lucid Lynx studio, 64 bit version. It’s fine except for a small issue which keeps cropping up, which is when I attempt to change the zoom on the audio tracks by using the mouse and control key, it sometimes quits with absolutely no explanation whatsoever. Is there an explanation or fix for this?
Just by any chance try disabling or removing plugins if you have any. I had similar issue with Invada meters, removing it fixed it. Never closed on me but became so sluggish and lots of xruns when trying to ctrl+mouse zoom.
I hope that’s your issue, if it is please post what plugin it was causing you this problem.
When I tried the Invada meters they appeared not to handle denormals properly which would explain why they cause things to slow down.
Hi suddentwigs,
that’s an old and difficult issue to track down:
http://tracker.ardour.org/view.php?id=2709
If possible, update to Ardour 2.8.11, even though it’s uncertain wether this problem has been completely resolved or not.
Benjamin
Invada meters are flawless here!
I found that the problem didn’t manifest itself on AMD cpus - it seems most denormal problems are more severe on certain intel CPUs (in my experience). Or perhaps there has been an update. Either way, when I tried it there seemed to be a problem that looked very much like it was caused by denormals (its not enough just to have the signal path handle denormals in a safe way, in the case of a meter, the signal level is usually averaged before being displayed on the meter, and if the averaging has a non-linear (exponential) decay, it may reduce towards zero in the presence of silence, but never actually get there, resulting in meter values that fall into the denormal range and slow down the processing, just as they do in the audio path). You can switch on various options in the host (Ardour) to help with denormal handling but it shouldn’t be the host applications responsibility. A plugin should be able to cope with denormals at its input without slowing down the system and it should preferably not emit them from its output.
@linuxdsp: its much more efficient for the host to use processor options if they are available. the plugin certainly should not try that, and doing it via conditionals and math is much much slower than the effects of setting FTZ or DAZ in the processor state for the process.
@paul: Agreed, it is more efficient to use processor options where possible, and the ‘convention’ such as there is one - is that a plugin should not alter the processor options (not least because it can’t know what effect this may have elsewhere) but in practice it has been my experience that implementing what is effectively a DAZ using conditionals has very little effect on the amount of processing used by the plugin (in the general scheme of things) and is probably the ‘safest’ solution. Its certainly preferable to doing nothing and hoping the problem is fixed elsewhere which unfortunately seems to be the case (knowingly or unknowingly) in quite a few other plugins. This is certainly an issue that is not as simple to deal with as it first appears, and there are many subtle ways in which the problems can arise, and it has been known to affect some quite expensive VSTs as well (I’ve worked on some of them in the past, and it can be quite ‘interesting’…)
I would love to upgrade to the new version of Ardour, as I am running 2.8.6. However, when I tried to upgrade to 2.8.9, the system still claimed to have 2.8.6 installed. Even if I removed the programme and reinstalled the lastest version afresh, it still declared itself to be 2.8.6. Peculiar. I have yet to try 2.8.11.