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

[Tim Blechmann]

> [...]
>  int sys_advance_samples; /* scheduler advance in samples */ [...]
>    /* exported variables */ int sys_schedadvance; /* scheduler
> advance in microseconds */ float sys_dacsr;
> 
> t_sample *sys_soundout; t_sample *sys_soundin; [...]
> 
> which means there is an additional sys buffer, which could be bigger
> than the Soundcardbuffer. I always thought pd needs at least 2
> blocksize for this buffer, but I had to look at the code if this is
> still true.
i just checked the code:

    sys_advance_samples = (sys_schedadvance * sys_dacsr) / (1000000.);
    if (sys_advance_samples < 3 * sys_dacblocksize)
        sys_advance_samples = 3 * sys_dacblocksize;

this seems to be, what you where referring to ... still, i don't see
the reason for this. neither native asio nor jack use this ... with
jack down to 64 samples ...
i don't think this has any technical reason, only prevents the user
from specifying lowest latencies ...

actually, i tested your latency-test patch on my machine ...
the results are:
jack (cb scheduler): 264 samples
jack (synchronous): 456 samples
native alsa: 200 samples
(period size of 128, 96000 kHz)

still, native alsa has some timing issues on my machine, resulting in
gliches, so i can't use it with block sizes lower than 256 at 96000
kHz, which results in a latency of 328 samples... (can someone confirm
that?)

but i'm pretty curious about the alsa implementation (i mean, a
callback driven alsa scheduler could reduce the latency even more) ...

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