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.
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.
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):
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
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 !
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.
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.
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…
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 !
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.
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.
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.