Hi all, i did some experiments with version 0.36 and i'm a bit disappointed that the audio (asio) part hasn't improved yet. I don't know if it's a PortAudio issue but i find it quite lame that under Windows (with a RME HDSP Multiface, digital loopback) i can't get stable audio with effective latencies under 30 ms. That may be ok for just playing sounds but it's not for live processing of instruments (for example percussion). The other thing is that using 18 in/18 out channels without any dsp load costs 16-20% of cpu (PIII 800) - that's just for audio IO! Has anyone had more success? How can the situation by improved?
It would also be less confusing if the devices listed with the -listdev flag (now one-based) would exactly correspond with those specified by the -audiodev flag (zero-based)
best greetings, Thomas
Thomas Grill wrote:
Hi all, i did some experiments with version 0.36 and i'm a bit disappointed that the audio (asio) part hasn't improved yet. I don't know if it's a PortAudio issue but i find it quite lame that under Windows (with a RME HDSP Multiface, digital loopback) i can't get stable audio with effective latencies under 30 ms. That may be ok for just playing sounds but it's not for live processing of instruments (for example percussion). The other thing is that using 18 in/18 out channels without any dsp load costs 16-20% of cpu (PIII 800) - that's just for audio IO! Has anyone had more success? How can the situation by improved?
Using Linux we have success reports of stable latency at <3ms with 10 tracks while using this device. With 24 tracks the latency creeps up to <10 ms.
My advice is to learn how to use a Linux machine and then you will have the best of both worlds.
Using Linux we have success reports of stable latency at <3ms with 10 tracks while using this device. With 24 tracks the latency creeps up to <10 ms.
My advice is to learn how to use a Linux machine and then you will have the best of both worlds.
Hi Patrick, i think i know how to use it - and i've been using it for some time, for installations and concerts. However, it's not the best choice for all of my (and possibly other people's) stuff... And above all, why not trying to improve the Windows ASIO port of PD as well? I've done some tests with pure PortAudio programs and i can say now that it's not the reason for PD's latency - i could achieve latencies down to 3 ms with 18 channels I/O with my RME HDSP under Windows. Concerning the cpu consumption... PortAudio is partly involved in it - there's some copying of signal vectors which eats up about 10% of cpu for 18 channels IO on my PIII-800.
best greetings, Thomas
On Sat, 14 Dec 2002, Thomas Grill wrote:
Hi all, i did some experiments with version 0.36 and i'm a bit disappointed that the audio (asio) part hasn't improved yet. I don't know if it's a PortAudio issue but i find it quite lame that under Windows (with a RME HDSP Multiface, digital loopback) i can't get stable audio with effective latencies under 30 ms. That may be ok for just playing sounds but it's not for live processing of instruments (for example percussion). The other thing is that using 18 in/18 out channels without any dsp load costs 16-20% of cpu (PIII 800) - that's just for audio IO! Has anyone had more success? How can the situation by improved?
There are two things, AFAIK with portaudio. One is, that portaudio is a callback based library. PD uses it in write/read mode, which is definitely not optimal.
The second thing is that I headr rumours that portaudio by default is configured to have a pretty high latency. You might be able to change this in some portaudio file. (This is really only a guess).
Under Linux, callback based JACK API, the minimum latency that is achievable with pd is 10 ms. This is due to the imprecise linux timers, it can be changed by recompiling your kernel.
Guenter
It would also be less confusing if the devices listed with the -listdev flag (now one-based) would exactly correspond with those specified by the -audiodev flag (zero-based)
best greetings, Thomas
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
There are two things, AFAIK with portaudio. One is, that portaudio is a callback based library. PD uses it in write/read mode, which is definitely not optimal.
The second thing is that I headr rumours that portaudio by default is configured to have a pretty high latency. You might be able to change this in some portaudio file. (This is really only a guess).
Hi Guenter, these the results of my test with a quickly sketched PortAudio test program (it might not be too clean....)
Portaudio latency (with ASIO - RME HDSP digital loopback): hdsp buffer = 256 samples -> latency 516 samples (= 11.1 ms) hdsp buffer = 128 samples -> latency 260 samples (= 5.9 ms) hdsp buffer = 64 samples -> latency 132 samples (= 3.0 ms)
The choice of the portaudio buffer size doesn't seem to have an influence (tested with 16,32,64). D/A and A/D conversion (RME Multiface) adds another 60 samples (what surprises me a lot).
best greetings, Thomas
-
guenter geiger -
Patrick Shirkey -
Thomas Grill