< Back to IRCAM Forum

Error using Pipo~ for live processing: "outputbuffer is full"

MuBu
#1

Hello everyone! Hope someone can help me here with an issue I’ve run into. I am using pipo~ mffc to analyise input audio for a mosaicing synthesis patch with MuBu inside MAX. At some point after turning DSP on and begin to get data, as early as 5 minutes, the module fails, stops working and posts this error into the console: “pipo~ ouputbuffer is full (condition occured 100 times)”. The same happens with other processing modules while live processing (descr, yin, fft, etc). When this occurs, I must restart the DSP engine.
Here are some variables I’ve tried to figure out a solution, with no results (currently running on Windows 10):

  • Run the patch in Max 8 and Max 7. No difference.
  • Tested the module independently in simple environments. No difference.
  • Changed different audio driver configurations (ASIO 512 samples 44100 khz). No difference.
  • Changed outputbuffer from Pipo module (really don’t understand how it works… maybe this is the problem). No difference.

But:

  • If I use my onboard audio card the error does not appear.
  • As a Max4Live device it works perfectly fine inside AbletonLive, even using my external audio interface.

The above makes me think there’s something wrong with my audio interface configuration. I am currently running on a Tascam US-16x08.

Hope someone can help me! Any help would be much appreciated!

Greets!

PIPO BUFFER
PIPO BUFFER393×730 86 KB

#2

Hi Augustin,

the outputbuffer is a queue that stores the results of the pipo modules (the mfcc frames) calculated in the DSP thread for output as messages in the scheduler high-priority thread. The pipo~ ouputbuffer is full message means that the patch following pipo~ can not keep up handling the data.
Have an eye on the CPU usage when this occurs. Also try to make it huge (100 * 1000).
Best

1 Like
#3

Hi Diemo! Thank you very much for your kind answer. I finally found what was happening. In the audio status menu there’s an “output limiting” option that should be turned off. For the rest, I followed your advice and set a buffer as big as it was possible to the pipo~ module. For more efficient cpu load I am also using a big buffer size in the audio driver configurations: 2048. I hope this helps because I am using 5 simultaneos pipo~ modules, 5 granular engines and 5 knn. Is there a way to precisely monitor cpu load from Max? Thank you very much again!

#4

Hi Augustin, I’m glad that you found the issue! I didn’t know about the output limiting option, that must be a Windows thing.
One more info: In Live, buffer size is fixed to 64 samples and audio interrupt is on, i.e. output messages are treated quickly and often, which explains the differing behaviour you saw between Max and Live.

Yes, that’s the right thing to do if you can live with the slightly larger latency.
To measure total cpu load, look at Activity Monitor or use spat5.cpu.

Cheers!