Are these figures good or bad?

Finances not being great, I’m still running Ardour on a lowly 1.2GHz Athlon XP. It’s an ageing machine and a couple of things on the mobo no longer work (e.g. I’m down to only 2 working USB ports). The onboard sound doesn’t work too well either although that’s less of a problem because I generally use my Hammerfall HDSP 9632. I’m pretty certain I could get an identical mobo on ebay and I could save myself a fortune (and a major headache) by not needing to upgrade the other components. OTOH, the credit crunch is making a new PC look very attractive.

If I run Ardour under 64studio (32-bit) and I just play 2 x simultaneous timeline clips with no automation and no plugins, my DSP reading is between 4.1% and 4.5%. If I launch qjackctl at the same time, its percentage reading (when Ardour and Jack are both running) is also around 4 percent. Are these figures good or bad? (or even meaningful). What kind of figures are other people getting?

One thing that’s probably significant is that I need to set my frames/period to 1024 to get glitch-free audio and I gather that’s a lot higher that a modern system should need.

Yup, you’re right; those numbers aren’t meaningful at all.
The only thing a slow CPU means is that you won’t be able to use that many plugins, and how many “that many” is, is totally dependent on what the plugin requires.

A compromise to save CPU cycles might be to put some plugins on a bus instead of putting them on the individual tracks, and then routing the tracks to the bus.

1024 f/p sounds a bit high for a Hammerfall though. Are you running jack in real-time mode and do you have something like

@audio - rtprio 99
@audio - memlock 250000
@audio - nice -10

in /etc/security/limits.conf and your user in the audio group?

Interesting questions Peder. My OS (64studio) supposedly runs a realtime kernel and for years I assumed Jack was running in realtime mode but now I suspect it wasn’t. The reason I believe this is that I recently started experimenting with jackdmp. When I run qjackctl (with jackdmp) I see the letters “RT” displayed in qjackctl’s display if I start jackdmp in realtime mode. However, if I run qjackctl with Jack as the backend, I never see the letters RT.

To answer your other question - I don’t have those entries in /etc/security/limits.conf but I do seem to have them in /usr/share/dpsyco/skel/etc/security/limits.conf

Another thing is that my mobo is an Asus A7V8X-X which (I think) uses a VIA chipset. Don’t ask me where I read this but I did once read that VIA chipsets are notorious for contributing to poor audio performance under Linux. Anyone know if that’s true?

I’ve heard that too, but my AMD 2000+ uses VIA chips as well and I run at 128 f/p on the standard openSUSE 11.0 kernel and an Audiophile 2496.
Maybe I could get down to 16 or 32 f/p with another chipset but hey; ~6ms latency is OK with me.

Jack/dmp doesn’t run in realtime automagically, it depends on what arguments you give (it’s -R for jack and I believe it’s the same for dmp) at startup.

I don’t really know how you’re able to run jackdmp in realtime w/o the audio entries in limits.conf (and your user added to the audio group) but try to do that and see if you can lower the latency.