@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.

I'm not sure that the fft has anything to do with it, except that I haven't otherwise had dropouts without high cpu usage.

Hi, I have a patch that is using rfft, similar to the phase-vocoder tutorial patch. It is operating accurately and reliably until I use a large window size while have a number of instances running at once. Then I start getting crackling sounds that sound to me like audio dropouts.
When I use the cputime object, it looks like I'm well below the threshold for where I would expect problems (hovering around 20%). Activity Monitor/Task Manager shows about 20% as well, and the total cpu load is low.

I am not surprised that there are artifacts when I have too many instances of the patch running at once, but I'm surprised that it doesn't show up as cpu overrun. Are there other diagnostic tools I can use that would help me predict when I will start to hear arifacts?
thanks