• AudioSolved

  • CPU usage and management with Pure Data patches

Hi! I'm working with a Bela with an audio expansion capelet and I'd like to know how to manage the CPU usage of my unit since when I run my patch on bela the cpu meter stays around 85-92% resulting, often in audio srtificies.
Project specifics: the patch weights 73 KB and is realised with pure data. It contains 8 audio generators (simple wave-filter-envelope) that send notes to 4 different outputs and 16 arrays recording audio from 4 incoming channels. I have not implemented yet players that use the arrays. When I run the patch on my laptop, the CPU never surpasses 8%. I've also tried taking the arrays out of the patch but, when run on bela, it stills stay around 75/80% of CPU usage. The IDE settings are [Block size: 2048], [Analog Channels: 8], [Analog Sample Rate: 22050].
Is there a way to better manage the cpu settings? Or is my patch too heavy?
Edit: I've also tried to break down the project with different abstractions, but the problem still persists!

    Luca Is there a way to better manage the cpu settings? Or is my patch too heavy?

    It seems like the patch is too heavy. It's hard to assess what is the main driver of the CPU usage from your description, but you should be able to separate it into smaller patches and measure the performance of each. If you add --board Batch --codec-mode p=95,s=1,t=2 to the "User command line arguments" in the project settings, it will briefly run offline and print stats on CPU usage of the patch (after removing any overhead from the Bela wrapping code), if that allows you to be more scientific in the investigation.

      Thanks, I'm trying that, but where will the CPU usage will be printed?

      in the console. It's Batch with a capital B (amended above)

      Great, got it! this are the results it gives me in the console:

      frames: 152064
      wallTime: 2.074610291s
      cpu: 60.166%

      I've also put in all the abstractions that I can and tested the single parts separately. They all stay around 20/25% of CPU usage so i think is just the sum of it all that becomes to heavy. Is there a way to lower the sample rate, vector size or latency? Even with the new adjustment half of my project is still taking up 80+ CPU usage!

      Baseline patch consumption due to I/O is probably around 10 % and that is not included in these calculations.
      Above 64 samples per block there is some extra CPU overhead that comes into play, so I'd try:

      • set 64 samples per block
      • remove the above command line options and replace them with --high-performance-mode

      If the IDE becomes unresponsive, press the button on the cape to stop the program.

      See where that gets you. From there, one can lower the sampling rate to get back some more %,.

      Unfortunately, that doesn't help much, it just lowers it by a couple of %, is my patch that complicated? Cause I don't think so!

        To change the sampling rate you need to run the command below in the console at the bottom of the IDE:

        sed -i s/44100/32000/g /root/Bela/core/*_Codec.cpp

        This will replace all occurrencies of 44100 in the audio codec files with 32000. You can select a different sampling rate if you wish instead of 32000. If you want to change this value later, you'll need to put after the first / the number that you want to replace and after the second one the number you want to replace it with.
        For instance:

        Go from 44100 to 32000:

        sed -i s/44100/32000/g /root/Bela/core/*_Codec.cpp

        go from 32000 to 38000:

        sed -i s/32000/38000/g /root/Bela/core/*_Codec.cpp

        go from 38000 to 44100:

        sed -i s/38000/44100/g /root/Bela/core/*_Codec.cpp

        Luca is my patch that complicated?

        I don't know, I haven't seen it.

          Ok thanks, I'll try and see what happens!

          Hi Giulio! I've started resampling some of the sounds from the patch and using them as samples instead of directly genrating them and, adding the lowering of the sample rate, I think I can build my patch again to have it be more CPU friendly. I now have a question about blocks dropped. I often find this error in the console:

          Underrun detected: 1 blocks dropped
          1 mode switch detected on the audio thread.

          It happens when a soundfiler reads a file into an array before playing it with a tabread~ object. How can I avoid that?

          yup, [soundfiler] stops the audio processing and goes to disk fetching the data from within the audio thread. That's bad for real time processing and thus gives you the dropped blocks. If at all possible, one should use [soundfiler] only at startup and use [readsf~] if you need to read files after the patch has started.

          14 days later