... Get more from CPU ?

Hi all,

I’m trying to mix for 1st time in Ardour, with many plugins, and CPU is really busy, Ardour says the HD is not speed enough in reading, and stop playback all the time.

How can I save some DSP%, to complete this mix with some automation, without tracking ?

I already change Jack settings to -R -P89 -p128 -dalsa -dhw:0 -r48000 -p1024 -n2 -Pplughw:0 -s -o2, in limits.conf there is @audio - rtprio 99 @audio - memlock unlimited @audio - nice -10, option for HD in fstab is noatime.

What more can be done to optimize the system ??

Thanks for the help !


I use htop to display rt prios.
It’s a ncurses (terminal) application, but you can use the mouse.
You have to configure it (disable Hide kernel threads, Hide userland threads …?), then sort by PRI.

/etc/init.d/rtirq status
1687 FF 92 - 132 0.0 S< IRQ-8 rtc0
1834 FF 87 - 127 0.6 S< IRQ-17 ICE1712
111 FF 50 - 90 0.0 S< IRQ-9 acpi
354 FF 50 - 90 0.0 S< IRQ-12 i8042
355 FF 50 - 90 0.0 S< IRQ-1 i8042
421 FF 50 - 90 0.0 S< IRQ-19 ata_piix, ata_piix, uhci_hcd:usb7
820 FF 50 - 90 0.0 S< IRQ-16 uhci_hcd:usb1, nvidia
857 FF 50 - 90 0.0 S< IRQ-18 ehci_hcd:usb2, uhci_hcd:usb5, uhci_hcd:usb8, eth0
858 FF 50 - 90 0.0 S< IRQ-21 uhci_hcd:usb3
859 FF 50 - 90 0.0 S< IRQ-23 ehci_hcd:usb4, uhci_hcd:usb6
1739 FF 50 - 90 0.0 S< IRQ-22 HDA Intel

Just found out that htop shows -51 when rtirq shows 50.

I don’t use /etc/init.d/rtirq start.
I have this in my boot.local:

set rt-irq for rtc and delta 1010

/etc/init.d/rtirq status|grep “$1”|awk ‘{print $1}’
chrt -f -p $1 pid_by_name "$2"
set -x
chrt_by_name 92 rtc
chrt_by_name 87 ICE1712
echo rtirq status:
/etc/init.d/rtirq status

Don’t set priorities for usb unless you are using a usb sound card or a usb disk (to store ardour sessions).
If so you should try to find out which irq it uses and just set this one.
I also do not set prio for i8042 (but i wonder if setting sirq-hrtimer and sirq-timer would help).

I use -P66 for jack.
So highest to lowest prio:
Timer, soundcard, jack, ardour.

htop (partially):

  • 3 root      RT  -5     0     0     0 S  0.0  0.0  0:00.02 migration/0
  • 13 root RT -5 0 0 0 S 0.0 0.0 0:11.50 posixcputmr/0
  • 15 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/1
  • 16 root RT -5 0 0 0 S 0.0 0.0 0:13.25 posixcputmr/1
  • 1687 root -93 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-8
  • 1834 root -88 -5 0 0 0 S 0.0 0.0 1h19:21 IRQ-17
  • 31115 bp -77 0 42036 25716 7728 S 0.0 0.6 0:00.00 /usr/bin/jackd -R -P66 -dalsa -dhw:1 -r44100 -p2048 -n2
  • 31116 bp -67 0 42036 25716 7728 S 0.0 0.6 0:00.30 /usr/bin/jackd -R -P66 -dalsa -dhw:1 -r44100 -p2048 -n2
  • 31118 bp -62 0 295M 69376 45940 S 0.0 1.7 0:00.02 qjackctl
  • 31143 bp -62 0 931M 228M 81980 S 7.0 5.8 0:05.78 /usr/local/lib64/ardour2/ardour-2.8
  • 4 root     -51  -5     0     0     0 S  0.0  0.0  0:00.00 sirq-high/0

Yes Seablade !

It was for resampling on the fly, cause Jack was running at 44099 or something like.

Sorry for this distorsion of Paul’s words, memory’s not the best part of my brain, just like on pc !!

Have tried to increase to 2048, but no real change…

For the “Jack thread” you talk about, sorry but my english’s not good enough… And translation on web means nothing I can understand… You means Jack settings needs to be change ?

In fact, I dig the problem for days now, and it appears this system really need some more RAM to do what asked !! Or maybe not, but can’t find anything !

I take your advice about freeze and don’t search for it !

Many thanks for all these answers, really helped. :slight_smile:

Hmm I suspect you may have misunderstood Paul by the way, I don’t think he would ever suggest using plughw for that purpose. Resampling on the fly maybe, but not for latency. And that resampling on the fly is likely taking more CPU compounding your problems.

You can always increase your latency by the way from 1024 to 2048, which will lower your CPU load slightly.

And of course export and reimport your session as I mentioned above.

And yes your Jack thread is likely preventing your HD from being accessed. Means you are running your cpu pretty dang close to maxed if not maxed out completely. It takes a lot to get that to happen on most systems.

And freeze while it still exists, does not seem to be applying effects to the tracks correctly.


to Adaw -what a cool name, should I write : a DAW !!-

What I can see with rtirq status command is :

90 - 130 0.0 S< IRQ-8 rtc0
85 - 125 0.0 S< IRQ-21 Intel ICH5
80 - 120 0.0 S< IRQ-17 ehci_hcd:usb1
80 - 120 0.0 S< IRQ-18 uhci_hcd:usb2, i915@pci
79 - 119 0.0 S< IRQ-19 uhci_hcd:usb3
78 - 118 0.0 S< IRQ-20 uhci_hcd:usb4, libata
75 - 115 0.0 S< IRQ-1 i8042
74 - 114 0.0 S< IRQ-12 i8042
50 - 90 0.0 S softirq-high/0
50 - 90 0.2 S softirq-timer/0
50 - 90 0.0 S softirq-net-tx/
50 - 90 0.0 S softirq-net-rx/
50 - 90 0.0 S softirq-block/0
50 - 90 0.0 S softirq-tasklet
50 - 90 0.0 S softirq-sched/0
50 - 90 0.0 S softirq-rcu/0
50 - 90 0.0 S< IRQ-9 acpi
50 - 90 0.0 S< IRQ-14 ide0
50 - 90 0.0 S< IRQ-15 ide1
50 - 90 0.0 S< IRQ-7 parport0
50 - 90 0.0 S< IRQ-16 eth0
50 - 90 0.0 S< IRQ-4

How can one know Ardour rtprio ?

Anyway, think you’re right, too much load on CPU !

Maybe the only action is buyin some memory…

Thanks for advice, what settings are you applying to Jack ??


maybe you can give some more information about your configuration and the mix itself (number of tracks, plugins,…)

I had the same issues when I first mixed with Ardour; this is what I did (following advice on here):

#1 As far as possible, put your plugins on busses so you can then use them by sending from individual tracks rather than having the same plugin appear individually in tracks

#2 Check the CPU use of each plugin - some are really heavy going. Drop the ones loading the processor, find alternatives.

Unless it’s a typo in your line you have both -p128 and -p1024. I don’t know which one jack chooses, but increasing the latecy will reduce the strain on the CPU.

I see you’re using the plughw: interface. Don’t use plughw: unless you have to. A hw: interface will probably use less CPU. The only reason I know of to use plughw: is if you need to use a sample rate that’s not supported by your hardware.


to Pleasebeus:

Good tips, thank you !

#1 I did it when don’t want a particular setting for a track

#2 You use the DSP=N% box in Ardour ??

to Dazgard

ok :

P4 with 1 GRAM, internal sound card
Lenny 5.01 with 64Studio 2.1 repos and some builded home applis
Jackd 1.9.2-0.64studio2~lenny1
QJack 0.3.2-1
Ardour 2.8 (4918)
There is 34 tracks and 8 bus in reading, only Jack and Ardour are
running, 29 plugins are used, most of them are C* Tube preampIV+tone and TAP Tube
warmth. The others are : Dyson comp, TAP reverberator, C* Eq 10 bands.
2 instances of C* plate2X2 and 1 of C* JVRev-stanford reverbs are on bus,
feeded with tracks pre or post send.

Ardour says disk reading is not speed enough
DSP=90% and more, sometimes it says 2.3%, I understand 102.3% !!!

Of course, can’t record the master outs on another stereo track…

to Peder

Not a typo, think 128 is number of ports, and 1024 frames/period. I test to increase to maximum this last value, but it was worse :frowning:

To Don

As far as I can remember, used plughw:0 for helping with latency in takes, as suggested by Paul Davis. You know, when Paul makes a suggestion about Ardour, what else can you do ? :-))

Anyway I try to come back to hw:0, and it don’t help at all, but internet was on for replying here.
If it’s ok without web using, let you know !

Thanks Don.

Yeah, pretty much - disable/enable to see how the cumulative CPU hit changes. Also, if you can be bothered to look at the documentation for each plugin, CPU loads are often mentioned.

to Pleasebeus

Thanks a lot, I notice TAP reverb is really hungry, and each C* Tube preampIV+tone takes around 3%. So, go to track down a lot, it was planned to forget when I come to Linux, but since waiting more RAM…

If you have a version of ardour in which Freeze isn’t broken, try freezing tracks you think you have the plugins set up right on - you can always unfreeze them later - and try and keep the number of unfrozens tracks you’re working on at any one time to a minimum.

If I’m really struggling and I have a bunch of tracks I know I’m going to keep together, like a herd of backing singers, I’ll deactivate everything else, route all of that section to a bus (perhaps containing plugins if I’m being really miserly with cputime), and then bounce the output of the bus to a stereo track, and hope I don’t need to come back to it. Of course I probably will, but each time the amount of tweaking I need to do gets smaller.

IIRC I switched from TAP reverb to C* Plates because of CPU load

Hey folks, there is a difference between CPU usage being the problem, and Disk Speed not keeping up. The latter has much less to do with CPU usage.

Disk usage comes as a result of the transfer speed of the disk being able to keep up with Ardour or not. Now a heavily loaded CPU will likely have a harder time reading as fast from the disk, that is true, but chances are this ins’t a CPU problem. As a random question, are you recording and playing back from your system hard drive by chance?


By the way, even if you can’t record the master outs in realtime, you CAN export your session and reimport, and disable the previous tracks to save both CPU and Hard Disk Access. Jack will go into freewheel mode for this, which means it will export as fast as it can, without a problem. In oyur case chances are this will be slower than realtime form your description.


Yea, at this point you are really hitting the limits of your computer on your session sadly. We don’t limit what Ardour can do on purpose(See PTLE with a 16 Track 2 Output limit, etc.), but it means things like this can happen when you overstretch your computer’s limits.