Hi,
This was just a thought and not a theme I need immediate answers.
I believe it is common understanding that Pd on Windows has much latency issues than on other platforms.
Has there been any attempts like, say, add native ASIO support to Pd? Is there any specific process towards the end of the chain which makes it difficult to add new types of outputs?
-- David Shimamoto
Hi, the incredible latency under Windows is actually not caused by portaudio. It's rather used by the fact that a ringbuffer is used to transfer audio data to the driver side. I don't know if the newer callback- based implementation (pd 0.41 or so, see the pd audio dialog) is also working under Windows - it should reduce the latency drastically. gr~~~
Am 14.09.2008 um 11:54 schrieb PSPunch:
Hi,
This was just a thought and not a theme I need immediate answers.
I believe it is common understanding that Pd on Windows has much latency issues than on other platforms.
Has there been any attempts like, say, add native ASIO support to Pd? Is there any specific process towards the end of the chain which makes it difficult to add new types of outputs?
-- David Shimamoto
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Well, I've seen latencies down to 6 msec in linux using ringbuffers. They theoretically only add 64 samples of latency. So I don't think that in itself is the problem.
I think the problem in Windows is the "audio server" that non-ASIO audio I/O apparently always goes through. Also, I think it's not feasible to use audio callbacks in Windows since Pd can make system calls (e.g., allocate memory) during the callback -- linux and Mac allow this but Windows doc says not to do that. (This shold be a leftover warning from older times but I've been heeding it anyway.)
cheers Miller
On Sun, Sep 14, 2008 at 05:42:12PM +0200, Thomas Grill wrote:
Hi, the incredible latency under Windows is actually not caused by portaudio. It's rather used by the fact that a ringbuffer is used to transfer audio data to the driver side. I don't know if the newer callback- based implementation (pd 0.41 or so, see the pd audio dialog) is also working under Windows - it should reduce the latency drastically. gr~~~
Am 14.09.2008 um 11:54 schrieb PSPunch:
Hi,
This was just a thought and not a theme I need immediate answers.
I believe it is common understanding that Pd on Windows has much latency issues than on other platforms.
Has there been any attempts like, say, add native ASIO support to Pd? Is there any specific process towards the end of the chain which makes it difficult to add new types of outputs?
-- David Shimamoto
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Well, I've seen latencies down to 6 msec in linux using ringbuffers. They theoretically only add 64 samples of latency. So I don't think that in itself is the problem.
I think the problem in Windows is the "audio server" that non-ASIO audio I/O apparently always goes through. Also, I think it's not feasible to use audio callbacks in Windows since Pd can make system calls (e.g., allocate memory) during the callback -- linux and Mac allow this but Windows doc says not to do that. (This shold be a leftover warning from older times but I've been heeding it anyway.)
Well, trying the forbidden way to use callbacks (and portaudio/ASIO or WDMKS, as implemented in the devel_0_39 branch) actually yield ADDA latencies below 5s for e.g. RME hardware, so the question is where the additional approx. 20ms of latency for the ringbuffer-based ASIO PD implementation come from. I've tried around a lot with the ringbuffer implementation, but it seems the "theoretical limit" of the ringbuffer implementation is just not approachable in Windows, for whatever reason. Besides that, I think we can just forget MMIO or DirectX for serious real-time audio. Also, this thread brings up the question how other programs do it (like Max/MSP or audio editing apps) - do they do something forbidden? Huh?! gr~~~
Am 14.09.2008 um 22:09 schrieb Thomas Grill:
Also, this thread brings up the question how other programs do it (like Max/MSP or audio editing apps) - do they do something forbidden? Huh?!
To answer my own question: Browsing through the Max/MSP SDK it becomes clear that there are quite serious restrictions what is allowed in DSP time. Pure Data is much more liberal here which of course has many advantages. And for audio editing the solution is probably that these systems are pretty static so that memory allocation and other critical processes are simply not needed.
gr~~~
Hi Thomas and Miller,
For some reason I thought that the latency was due to Portaudio. So in short, is the current consensus that the cause is somewhat "uncertain"?
-- David Shimamoto
Well, I've seen latencies down to 6 msec in linux using ringbuffers. They theoretically only add 64 samples of latency. So I don't think that in itself is the problem.
I think the problem in Windows is the "audio server" that non-ASIO audio I/O apparently always goes through. Also, I think it's not feasible to use audio callbacks in Windows since Pd can make system calls (e.g., allocate memory) during the callback -- linux and Mac allow this but Windows doc says not to do that. (This shold be a leftover warning from older times but I've been heeding it anyway.)
Well, trying the forbidden way to use callbacks (and portaudio/ASIO or WDMKS, as implemented in the devel_0_39 branch) actually yield ADDA latencies below 5s for e.g. RME hardware, so the question is where the additional approx. 20ms of latency for the ringbuffer-based ASIO PD implementation come from. I've tried around a lot with the ringbuffer implementation, but it seems the "theoretical limit" of the ringbuffer implementation is just not approachable in Windows, for whatever reason. Besides that, I think we can just forget MMIO or DirectX for serious real-time audio. Also, this thread brings up the question how other programs do it (like Max/MSP or audio editing apps) - do they do something forbidden? Huh?! gr~~~
I hear that using ASIO4ALL on Windows can help quite a bit:
.hc
On Sep 14, 2008, at 5:54 AM, PSPunch wrote:
Hi,
This was just a thought and not a theme I need immediate answers.
I believe it is common understanding that Pd on Windows has much latency issues than on other platforms.
Has there been any attempts like, say, add native ASIO support to Pd? Is there any specific process towards the end of the chain which makes it difficult to add new types of outputs?
-- David Shimamoto
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
kill your television
Hi Hans,
I hear that using ASIO4ALL on Windows can help quite a bit:
If my understanding is correct, this is more of a rapper which adds ASIO support to hardware not designed to. As a side effect it reduces latencies on mainly AC'97 chips which is fun when working with on (mother) board interface, but is not so useful with hardware that support ASIO to begin with.
Although that is just my view, I did try the latest version just now which was not even close to virtually wire speed I experienced with the same hardware under Ubuntu.
P.S.
BTW if Mathieu is around.. The gimmick of "advanced mode" labeled with a photo of Einstein versus "simple mode" being George Bush seems to have been removed from the latest version of this software.
-- David Shimamoto
.hc
On Sep 14, 2008, at 5:54 AM, PSPunch wrote:
Hi,
This was just a thought and not a theme I need immediate answers.
I believe it is common understanding that Pd on Windows has much latency issues than on other platforms.
Has there been any attempts like, say, add native ASIO support to Pd? Is there any specific process towards the end of the chain which makes it difficult to add new types of outputs?
-- David Shimamoto
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
kill your television
-
Hans-Christoph Steiner -
Miller Puckette -
PSPunch -
Thomas Grill