[PD-dev] Re: [PD] RME hammerfall

[Tim Blechmann]

> 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

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

latest mp3: kMW.mp3
http://mattin.org/mp3.html

latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs