high CPU usage only when transport stopped?

Howdy. I am currently running version 2 of Ardour under the Ubuntustudio distro. I am encountering a weird problem that I am wondering if anyone else has run into and might have suggestions on how to correct.

What is happening is that Ardour is ending up in a situation where hitting stop on the transport quickly results in massive CPU usage. If I can trigger the transport to start, this CPU usage drops back to normal but as soon as it is stopped, the issue occurs again.

This may be related to use of the TAP EQ plugin though I do not have enough anecdotal evidence to say that for sure. I initially thought this was a bug with Jamin but after removing Jamin from the equation it was still occurring (after a restart of Ardour even) so I do not think that is the problem. One thing I did notice was that there was some sort of feedback loop in the Jack connections - could this be related?

Currently my Ardour box is not connected to the Internet so I wanted to see if this was a known issue (fixed maybe?) before I went to the hassle of trying to change that situation.

Cheers!

I found most of the TAP EQs to be unusable on my AMD64 system (I haven’t had a chance to try 2.0.3 yet). The FIL plugins (fil-plugins package in Debian and presumably also Ubuntu) include a nice four-band parametric EQ that works well and is stable without having to apply any denormal workaround stuff.

You should upgrade to 2.0.3, and take advantage of the new denormal protection it offers.

Denormals are a feature of the Intel processor series, and cause the CPU to slow down very very dramatically when doing math with very very small floating point numbers (such as the values close to absolute silence that show up when the transport is stopped).

2.0.3 offers both use of processor features (on by default) and the optional addition of a small (utterly inaudible) constant value to samples to avoid denormals.

Thanks for the response. Would this also affect Athlon processors? The machine in question has an XP1800+ in it, definitely no Intel hardware in sight.

=)

Also, the issue does not happen all the time and has only started appearing as I have been mixing down. I haven’t run into it previously during recording though I also don’t use plugins at that stage normally.

Cheers

by Intel, I really meant “processors functionally adhering to the x86 design”. Some AMD processors handle denormals a bit better than some Intel processors, but not enough to make the problem go away. Among mainstream processors, the PowerPC is one of the few not suffer from this design detail.