hi,

i have a huge patch and noticed a big difference in cpu load shown by the load meter of the purr data window and the load shown by my system monitor. the system monitor shows around 4 % and four subprocesses (that are part of my patch with four pd~) at 4% each.
if i check the included load meter of purr datas main process i get up to 50 % though. i do get audio dropouts when i run it. everything should check out.
do NOT visible gui elements that are parts of subpatches have an effect on load even when you can't see them? is there a limit to what the program can handle regardless of the cpu? what could be the reason for the difference in numbers?

WRT real-time audio, the most important performance factor is: will the next hardware buffer's worth of audio be ready on time?

If we assume a 512 sample hardware buffer and a 48 kHz sample rate, then each hardware buffer takes 10.6666667 ms.

If the audio calculations finish in 1 ms, that's roughly 10% of the available time. If they finish in 5 ms, that's 50%.

RT audio calculations tend to happen in bursts. IIUC (I could be wrong) system CPU monitors are looking for sustained CPU activity, which does not characterize RT audio. So the system monitor might tell you that the system isn't very busy, but the DSP thread might actually be stressed.

For instance, I just ran a bunch of DSP in SuperCollider and it reported about 38% CPU use, but the system task monitor reported 4%. (But htop showed one CPU core with high activity, and the rest mostly idle... so a single CPU usage number that aggregates all the CPU cores can also under-report.)

I think I remember reading here that Pd does its audio calculations outside of the audio driver's callback, and uses the callback only to copy data, meaning that audio subsystems like JACK in Linux might significantly underreport CPU usage. So the whole thing is a bit of a tricky question. I don't know how Purr Data is measuring CPU use.

hjh

hey thank you so much for your insight. it is a tricky question indeed. the more i learn about computers the more i am loosing my mind. with each evolutional step in a patch i amount more variables on my path to failure. i hadn't considered that there even could be different ways of measuring CPU load. so thank you, that gives me some hope. do you know about any other way of multi-tasking the DSP thread? other than pd~ subprocesses? i am using vst and ladspa plugins in my patch. some, like the trackspacer plugin, are very expensive in terms of CPU. I am starting to find other options like florah lite. but still, do you know a way of encapsulating/delegating specific operations of a patch to individual tasks other than pd~? it seems (i have no proof at all) pd doesn't make good use of multiple cores.

@pholypp I shouldn't really comment without seeing your patch.
Some os's auto-allocate cores to threads, some allow you to define the allocation. Some give no such option. What tools are available for e.g. measuring processor latency, again depend on the os.
Pd does all the control rate processing between audio blocks, but modern computers are able to cope with that. However, as you say, GUI redrawing can interrupt the patch (especially in windows).

I run a huge patch for a live show...... basically a whole mixing console with OSC control over Wi-Fi...... and had occasional problems.... caused by Adobe updater and the software for the fingerprint reader. That took a while to find.

You could try stopping such other software that might cause interrupts, and turn off Wi-Fi. There are a few articles from e.g.Native Instruments about fine tuning computers for audio.
Bad drivers can also be the culprit....... anything that interrupts the processor.

If you have a lot of dropouts and you are not running a live show then increasing latency could help.... i.e. increasing buffer sizes for audio threads to sound cards.
That can be set in Pd for on-board sound cards.... "Delay (mSecs)".
For your VST's you probably need to set the buffer size in your DAWs.
For your professional soundcards buffer sizes will be set in the driver control panel.

Using Pd under Linux I think you can set audio thread priority with the -realtime startup flag.
David.

@whale-av said:

Using Pd under Linux I think you can set audio thread priority with the -realtime startup flag.

Doesn't the realtime startup flag just enable the use of realtime audio (the default)? --help does not mention arguments, is this one of those features which was only documented on the dev mailing list? But in linux we do have various ways to give things greater priority such as nice and can go all the way to running an application on its own isolated core and even use a preemptable kernel so an application can have a higher priority than the kernel.

@whale-av I disagree, you should absolutely comment without seeing my patch. maybe i shouldn't ask these questions without posting my patch. but my patch is confusing with many layers and self-made modules, some of them dating years back. back to when i started with pd and thought it is not so important to keep everything clean and tidy. i am already on the slow side regarding latency. thank you for the help. i am curious, how did you find the problems with adobe updater? sounds like you have a plan when it comes to debugging?
it's a different topic but since you mentioned sound cards: have you experienced less drop-outs with a much better quality soundcard? in my mind this shouldn't be an issue with only virtual inputs and a modern interface, but i have no clue about that.

thanks to both of you, i will look into nice as well since i am on linux. as a note to myself and anybody who might read this: as i mentioned i have some vstplugin~ in there, like trackspacer which consumes a lot of CPU. i just read the vstplugin~ help file and you have optional flags to run the plugins in individual subprocesses. i will try these and it should solve my issues for now. thank you all for the great info. i learned a lot by not reading the manual first

@pholypp Soundcards is a difficult one to nail.
I have had a Motu 828 that would run for hours without any problem and then suddenly produce spikes on some or all outputs until a preset was reloaded (much quicker than a reboot).... and then be happy for days until the next time. The driver settings would often not stick when changed..... reopening the driver panel the settings would have changed to something else, but serial data streams have to be negotiated so...?

Other Motu's (different drivers) have never had a problem.
I don't think they are manufactured with problems, or that the 828 had any electronic faults.
It is much more likely that the 828 driver had problems talking to the os, On my mac the keyboard and the trackpad and the CD drive are all on the same hubs as the USB ports, which cannot help.

Some USB soundcards will work on one USB port but not on another, probably because something else (keyboard, something?) is on the same bus and so the bus timing has been downgraded to USB 1 from 3 or 2

Trial and error all the time....... especially with the Adobe updater, where I had force stopped just about every service on the laptop in desperation. Adobe updater always ran as a delayed start service at boot. Adobe licensing also, but fortunately without causing problems.

I am no expert in such things, but with so much software trying to control so much hardware nowadays how can anyone be sure....
It's a bit like a doctor having to hope that you can take aspirin + X when you have Y and Z but they don't yet know what Z is.
It seems to me that if it is mission critical then it should be bare bones and never receive an update.
I don't ever connect my show laptops to the internet.
David.

i just read the vstplugin~ help file and you have optional flags to run the plugins in individual subprocesses. i will try these and it should solve my issues for now.

Running the plugins in individual subprocesses (with the -p or -b option) will not reduce CPU load - on the contrary! This feature is really meant for sandboxing, i.e. the plugin can crash safely without taking down Pd.

What you can do is open the plugin with the -t flag (= multithreading). This will run the plugin in a helper thread, so the main audio thread is free to do other things. It works quite well in practice. Give it a try!