again, I'm really sorry for multiple posting, but there was a problem and the mail may not have been actually sent (I still don't understand why I had to double-post my last messages on pd-list ; any idea ?)
----- Message transféré de brevalju@etu.utc.fr -----
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 ============================================================================
actually, I don't know what the "-asio" flag automatically imply :
- does pd automatically choose the ASIO Hammerfall driver ? (and not DirectX,
Multimedia or another ASIO or ASIO-compatible driver) ; I think it does, because "-audioindev 2" and "-audiooutdev 2" is the device number of the HDSP on my computer
- does pd use a 128-sample audio buffer (or any other size specified in the
sound card panel) ---- so "-audiobuf 3" would be useless
Thanks for your help, j
julien.breval@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
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).
I seem to be luckier I didn't make any objective measurements, but hearing it I get very good results
My PC is a Shuttle SB51 with P4 2.4GHz, and WinXP pro, and also Linux
as far as i remember i didn't use the "-blocksize" option (don't know why; probably it had no effect)
I think this regards the pd internal vector size ; the smallest it is and the most performant it is (but more CPU too) ; default is 64 samples ... I put it to 128, it's stupid of course I thought it corresponded to the sound card I/0 vector size (I should have used "-audiobuf" of course)
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)
well, I prefer Linux too, but I have complex ALSA problems because my HDSP was too recent -- it should have been fixed now, and I will try to re-install Linux PlanetCCRMA ... in april (loads of work since september !)
big tip: use your task-manager to prioritize the pd thread to "real-time" and the pdgui-thread (wish83) to "lowest".
will try this
thanks a lot for you advices
j
Still under WinXP and pd-0.36
Well, I don't understand a lot of things about it :
when I launch pd with the "-audiobuf 3" flag (so the sound card buffer size / latency should be 128 samples / 3 ms.), I get this message :
============================================================================= nchan 8 flags 3 buffers 0 framesperbuf 256 warning : number of buffers 0 less than recommended minimum 2 =============================================================================
no latency, but the sound is completely distored (~ buffer error)
When I add the "-blocksize 128" or "-blocksize 64" flag : ~ same results ("framesperbuf" looks to be controlled by the "-blocksize" flag)
to avoid this, I have to put at least "-audiobuf 15", and I get this message :
nchan 8 flags 3 buffers 4 framesperbuf 256
and too many latency of course
strange : when I don't use "-audiobuf", I get :
nchan 8 flags 3 buffers 8 framesperbuf 256
Is it really the ASIO Hammerfall driver I am using ? how can I be sure ?
Before I switch again to Linux, please tell me which pd command line you use successfully under WinXP-pro
thanks a lot
j
I get this exact same problem on OS X. .. I've mentioned it before on
the list, but there really hasn't been a solution as of yet.
Any less than a "buffer 15" setting and sound is completely distorted..
I'm using the MOTU 828mk2
/* Matt Nish-Lapidus
www.ekran.org/mn-l matt@ekran.org // mattn-l@rogers.com
"What's this fish doing in my ear?" */
On 10-Mar-04, at 9:53 AM, julien.breval@tremplin-utc.net wrote:
Still under WinXP and pd-0.36
Well, I don't understand a lot of things about it :
when I launch pd with the "-audiobuf 3" flag (so the sound card buffer
size / latency should be 128 samples / 3 ms.), I get this message :=======================================================================
nchan 8 flags 3 buffers 0 framesperbuf 256 warning : number of buffers 0 less than recommended minimum 2 ======================================================================= ======
no latency, but the sound is completely distored (~ buffer error)
When I add the "-blocksize 128" or "-blocksize 64" flag : ~ same
results ("framesperbuf" looks to be controlled by the "-blocksize" flag)to avoid this, I have to put at least "-audiobuf 15", and I get this
message : ======================================================================= ====== nchan 8 flags 3 buffers 4 framesperbuf 256 ======================================================================= ====== and too many latency of coursestrange : when I don't use "-audiobuf", I get :
====== nchan 8 flags 3 buffers 8 framesperbuf 256 ======================================================================= ======
Is it really the ASIO Hammerfall driver I am using ? how can I be sure
?Before I switch again to Linux, please tell me which pd command line
you use successfully under WinXP-prothanks a lot
j
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
IOhannes m zmoelnig -
julien.breval＠tremplin-utc.net -
Matthew Nish-Lapidus