achievable latency
latency that is achievable by a certain system. the lower limit is given by the system-latency. the actual value depends on the system-load
'ok, in theory my system has a latency of 8ms. i have confirmed this value on my brandnew pentium4-3GHz with a simple patch that just connects the outlet of the [ adc~ ] to the inlet of the [ dac~ ]. Now i wanted to fiddle around with my over-hyper-super-cool-guitar-wha-effect-fuzzer patch and it doesn't produce any intelligent output but clicks and crackles. i have to resize pd's audiobuffer to a 200ms to make them go away. now the effect is not usable for me any more.'
because of cpu-bursts, pci-bursts, dma-bursts and i don't know what else, the system-latency will often be unachievable. so what ?
- hardware :
get the newest !
seriously, we need a list of which hardware-specs are important
- graphics(!)
- ethernet(?)
- DMA-controller
- harddisk (esp. when doing soundfile recording/playback)
- ...
- operating system :
of course this depends on your OS....
- linux:
lowlatency-patch, preemptive-patch, 1kHz-patch
...
- windows:
- macOS-X
- linux:
- driver :
most probably nothing you can do here
- pure-data :
???
- patch : here could be done most
- algorithm: use other, less cpu-expensive algorithms
- soundfiles:
- use a fast separate harddisk (RAID) for your sound-files
- use tables instead of reading soundfile on-the-fly from disk (note: be sure, you have enough RAM)
inspection of the [ readsf~ ] code. does it block the main-process ?
- messages vs. signals:
- generally, calculations done in message domain are less expensive than calculations in signal-domain, because they are only done every now and then.
- message-calculations at or near sample-rate are (supposed to be) highly inefficient. rather use signals for this
- complex calculations in message-domain might cause peaks in the CPU-load, resulting in dac-slips (if the audio-buffer is to small). pd does not attempt to schedule messages (being asycnhronous by definition). write your own scheduler with the aid of [ delay ], [ pipe ] et al.
note that [ del 0 ] doesn't mean "zero delay" but "as soon as possible"