Hi,

I am on a Raspberry Pi 3 and I have Pd .46 .2 . I admit the patch I am working on is sort of a monster patch with a few big abstractions. But in the Audio Settings I increased the block size to 2048 and I set the Delay to 100 msec. That eased things up and everything was working fine.

However a few objects weren't loading properly when I launched my patch including tanh~ so I added -lib zexy as a startup flag. After I did this the CPU load got really high, it fluctuates between 75 and 99, and the audio is really glitchy. A lot of the time my midi controller gets somehow disconnected and I can't even stop or turn down the volume.

How can I lower the CPU load for Pure Data? Or increase the processing power for Pure Data from the computer? Are there any settings I can try or settings I should do?

Thank You.

Nick

@nicnut I am not sure that setting the block-size high is really helping....... the advantage will be slight, but it is important that it is matched to your soundcard. The delay (buffer) will help with glitches, but increase the latency, so should be set just high enough to stop any glitches. The Delay (mSecs) is what you see referred to as buffer.... in samples..... elsewhere..... so for example at 44.1KHz Delay 100mSec is a buffer of 4410 samples rounded down to 2 blocks.....
You might have the Linux -rt (real-time for audio) switch available on the Pi which could help with glitches...... add -rt to Pd preferences "startup flags"
Good practice is to hide arrays in sub-patches, and reduce any screen drawing to an absolute minimum. All the gui stuff is being done between audio ticks, and screen drawing can take too long.
Video cards, Wi-Fi cards, interrupts (especially usb)....... everything else the computer is doing..... can cause glitches by taking too long to complete.
Check out the tuning tips found here........ https://support.native-instruments.com/hc/en-us/search?utf8=✓&query=windows7+tuning+tips for windows and osx but always relevant.
Check out chapter 2.4.2 onwards here as well........ http://puredata.info/docs/manuals/pd/x2.htm

You might need a powered hub for your usb midi. There might not be enough power for it as the Cpu load gets heavy.
David.

According to the patch of course, I like to go down to 32kHz. Lo-fi sound.

Hi,

in general when functions like [tanh~] eat up too much cpu you can use either one or the other of these strategies:

• table lookup, see for example Chris McCormick e_tanh.pd
• numerical approximation, like Taylor series or others, among them is this formula : tanh=~x * ( 27 + x * x ) / ( 27 + 9 * x * x ), see this

Nau

Hi, Thank you all for your replies.

I deleted several instances of a granular delay effect and created a bus so everything shares one delay. It helped a little. Now my CPU load is around 50-75 and still glitches occationally. Yesterday Pd and the Pi completely crashed while I was jamming out on my patch so I wouldn't feel comfortable performing with this setup in public.

So @whale-av, If my soundcard is at 44100 and I have a block size of of 2048 my delay should be 50 millisec correct? and as I lower the block size, by half, I lower the msec delay accordingly correct? I haven't noticed much help from messing with those numbers., except when the block size was 64 everything was totally not working.

I don't have any video cards, wi-fi or anything else. I do have a USB midi controller. And I am using a battery to power my PI, but it doesn't seem to matter if it's battery powered or plugged in. I think my problem is in my patch because another smaller patch runs fine. And I have been limiting using gui stuff.

I will try out the Linux Real Time for Audio switch. I'll download that today and report back.