FW (sorry) : [PD] Hammerfall : setting up latency for Pd

[IOhannes m zmoelnig]

julien.breval at tremplin-utc.net wrote:

> hello
> 
> All this happens under Windows XP
> 
> I discovered there was a slight latency when I use [adc~] with my sound card, 
> and it would be good to reduce it (I currently don't have any performance 
> problems)
> 
> in the configuration panel of the HDSP card, "Buffer Size (latency)" is 128 
> samples (3 ms)
> 
> which command line should I use for launching Pure Data ?
> 
> the current one is :
> ============================================================================
> pd.exe -r 44100 -inchannels 8 -outchannels 8 -audioindev 2 -audiooutdev 2 -
> asio -blocksize 128 
> ============================================================================
> Therefore only the pd internal I/O audio buffer size is explicitely specified 
> here, not the sound card I/O audio buffer size
> 128 is weak for "-blocksize", I should set it to 2 or 4
> 
> 
> So maybe this one would be better :
> ============================================================================
> C:\pd\bin\pd.exe -r 44100 -inchannels 8 -outchannels 8 -audioindev 2 -
> audiooutdev 2 -asio -audiobuf 3 -blocksize 4 
> ============================================================================
> 

hi.
the measurements i have done with the HDSP/winXP have not been very 
satisfying.
the main problem used to be, that measurements tended to be 
not-reproducable under winXP (as they were under linux)

test system was an athlon-XP3200+ machine (winXP-pro).

as far as i remember i didn't use the "-blocksize" option (don't know 
why; probably it had no effect)
the "-audiobuf" should be at least the corresponding value to the 
buffer-size you set at the control-panel (for a buffersize of 128, use 
3ms of audiobuf)


i didn't get any reasonable results with a buffer-size below 256.
the best result i got was about 2179 samples (which is 50ms @ 44.1kHz)
but it was not very stable (at least at at CPU-load of 80%)
(but it really performed quite erratically: e.g: with an rme-buffer of 
2048 samples (which gave me a latency of 6019 samples) i didn't get 
*any* good signal, even at a virtual load of 0% !!)


that was the main reason, why we chose to use linux even more for 
latency-critical applications. (at least we could do 835 samples latency 
  with a load of 50% on the same machine with alsa/jack; and without 
file-access (this does not mean writing to soundfiles, but rather saving 
big-files at once) during dsp-processing the system gave us a stable 
latency of 1603 samples at 80% cpu-load)


but really, for low latency the old rme-hammerfall cards (which are not 
sold anymore) with OSS drivers performed best:
without filesystem-access it gave us latency of 193samples, even at high 
load (80%).
with the need to read and write files during the processing at high 
load, we got 961 samples latency.

quite disappointing.


big tip:
use your task-manager to prioritize the pd thread to "real-time" and the 
   pdgui-thread (wish83) to "lowest".


mfg.as.r
IOhannes