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

[Winfried Ritsch]

Hallo,

> > [...]
> >  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 
memory,.... 

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 
latency time. 


>
> 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
> that?)
>

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.

mfg winfried