Personal tools
You are here: Home members ritsch's Home PD Latency achievable latency
Document Actions

achievable latency

by Winfried Ritsch last modified 2004-10-21 09:31 AM

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
  • 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"


Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser