[PD-dev] Re: [PD] RME hammerfall
ritsch at iem.at
Tue Apr 19 10:07:07 CEST 2005
> > [...]
> > 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 ...
The reason I think is historical and going back to the ISPW, 2 i860 cpus on
an extra card running fts where you can distribute working load to dedicated
cpus udn need to have latencies because of signal distribution on shared
Nevertheless I think since all messages are calculated before the dsp-stuff
each tick, the chance to have a FFT-Border and a lot of messages triggered
eg. by bang~ at the sametime can easily exceed the buffer size so its better
if you distribute the message calculation in finer grains, therefore its good
to have at least 2 (3) dacblocks as a sysbuffer, even if you use a 64sample
buffer on hardware. If you really need (it will be nice you write down a
Use-case) and want to go unter say 3*64 ca. 3.5ms, you its better to mach
DACBLKSIZE smaller, which works on most and all well written objects, fine.
Also be sure pd is never blocked less then time of a syssamples, which I did
with increasing the scheduler rate from 100Hz to 10000 in ancient times ;-)
I think using higher samplerate is the same as reducing DACBLKSIZE to reduce
> 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)
should be 2ms which is very small.
> 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
I dont know if it depends on alsa mmap implementation, but code is not really
test to much since when I got latency about 5ms I was already happy und i
didnt need more.
> but i'm pretty curious about the alsa implementation (i mean, a
> callback driven alsa scheduler could reduce the latency even more) ...
I dont exactly know what jack does, but since alsa makes direct memory access
and can copy samples to buffer in smaller units than buffersize of hardware
and also watches the write read pointer from rme hardware card (use
precise_ptr on module load), you theoretically can go smaller than 64 samples
on as hardware buffer ;-) so you should can go down until I think 8 samples
(PCI Bridge Buffer with 26channels) , depends on pci bridge on computer.
More information about the Pd-dev