I think since pd use a internal blocksize of 64 und you need at least two of them, you have to reduce the pd blocksize to get latencies below 128 Buffersize. (see and please correct http://puredata.info/Members/ritsch/latency http://puredata.info/Members/ritsch/latency/pd_structure )
actually, i don't see, why you need buffer sizes of 2 blocksizes ...
basically there are two ways to design a scheduler, the synchronous and the callback-driven schedulers:
for the synchronous scheduler (which is currently the main scheduler), dsp will be computed in the main scheduler thread. the callback from the audio hardware just copies data from and to the in buffers and out buffers:
1. copy data to audio hardware copy data from audio hardware 2. compute dsp 3. same as step one. at the time of the next callback
this basically means, that audio data is being copied to the pd thread, the pd thread is computing dsp and at the time of the next callback, the processed audio data is copied to the outlets.
for the callback-driven scheduler (which i implemented for native asio and jack in devel), the dsp is computed not in pd's main thread, but in the callback thread. as far as latency concerns it performs better:
1. the callback copies data from the audio hardware to the input buffer 2. the callback thread computes dsp 3. the callback thread copies the data to the audio hardware again, without waiting for the next callback
both schedulers have good and bad features... - the callback driven scheduler reduces the latency by one block size - the callback driven scheduler is working in a second thread, which means, the sys_lock() has to be locked... on the other hand, locking a mutex in an realtime thread is not a very good idea ... this may cause problems, if the cpu load is very high and there is a lot of messaging / gui activity. other options to stay threadsafe would be to compute control data at downsampled audio rate (see supercollider) or to rewrite _all_ dsp objects to be threadsafe by using lock-free algorithms
still, i don't see the point, why either of these schedulers should require blocksizes that are twice as big as pd's internal block size, since it's just the question, if where in the dsp scheduling we wait ...
cheers ... tim