Realized I might be unclear- by pd~ I mean the vanilla object called [pd~] that allows running another instance of pure data to process audio on multiple cores.

Hi, I read through the help file for pd~ and most of it makes sense, but the -fifo flag has me scratching my head. The documentation says "number of blocks for round-trip (default 5)."

I feel like the combination of external block size, internal block size, and whatever limitations are baked into the code should dictate this...
What are the ramifications for overriding the default? how do I choose a value?

thanks

@dreamer would that be for reducing cpu further after I've downsampled?

@ddw_music
I'm doing some experiments with cross correlation; hoping I can locate a point source in a stereo field. The higher the sample rate, the better the resolution I can get. So I need the original data at high frequency, but after I do the cross correlation calculation, I'll process it in more normal audio ways that don't require anything above 48k. That's why I think hardware input needs to be at 192k, rather than upsampling a 48k input.

Thanks for your pointer about filtering!

I want to use a 192k sample rate for input from dac~, do some processing that requires the high sample rate, and then have the rest of the patch operate at 48k, because I don't think my computer can handle the whole patch running at 192k and I don't need 192k for most of what I'm doing.

Is it as simple as the project being set to 192k, the main patch running at that, and then all the lower sr stuff being embedded in a patch with a block~ object downsampling to .25? I won't lie; up/down sampling kind of bends my brain, and I'm not sure if there will be a bunch of inintended audible consequences, or if the downsampling/block strategy will save me as much cpu as I'm hoping.
Any hints or comments?
Thanks

I'm trying to half-fill a table. I'm using tabwrite~ within a patch that has block~ set to half the table-length. The results are good with a block size above 64, but below that, it fully fills the table. I know pd's default block size is 64. Is this related? Or is there something I'm missing?

I notice if i down-sample the block, I can get the results I want. downsampling to .5 gets desired results at 64, and .25 gets me 32. I feel like there's something basic about dsp that I'm not getting. I don't understand why I need to downsample?

I've attached a simple example patch, but it doesn't do the downsampling (just add .5 or .25 at end of [$1 1] message in pd zero_pad

paddedTest.pd

Has anybody used kiosk-plugin (via deken) on a raspberry pi?
I downloaded and tested on osx and it works great, but when I try on the raspberry pi, the options I tried (disabling menus and making full-screen), didn't work. The console seems to think the plugin is loading properly. Is there a known issue?

pd version 0.51.4,
rpi os bullseye

Reading a bit, it seems that 50 is the default. I have no idea how mine ended up so low. My laptop isn't so old, and I was a bit surprised that everybody was getting better results than me haha. Anyway, I'm going for responsive, so I'll keep it as low as I can without getting those dropouts. Thanks again

Thanks for all the thoughts!
@whale-av @jameslo you were right about the audio delay. Increasing from 5 of 8 ms did the trick!

Thanks for replying. It's part of a pretty large project and woud be hard to isolate, but I've reproduced the dropouts with something simpler:

fftDropoutExample.pd

It is literally the phase vocoder tutorial patch with a whole bunch of extra fft-analysis windows running simultaneously. my cpu is at 16% but there are loud clicks at random intervals.