Quoting mattn-l@rogers.com:
is this because of portaudio on os x?
yes.
or is there something i can do about it?
start here: http://developer.apple.com/audio/macosxaudio.html
i have too much on my plate right now to rip all the portaudio out of pd and replace it with straight CoreAudio calls. but that's what someone needs to do...
i'd love to be able to work on this, but i'm not really a c programmer.. i am willing to learn however. do you have an suggestions/recommendations on where to start?
matt.
1
mattn-l@rogers.com schrieb:
i have too much on my plate right now to rip all the portaudio out of pd and replace it with straight CoreAudio calls. but that's what someone needs to do...
Yes, I think so too. So the question is whether it's worth to use portaudio in general or not. Looking at the sources it seems that since the introduction of portaudio into Pd we got at least one additional audio buffer (and thus additional latency) for each input and output. I know that portaudio makes it easier to develop Pd beacuse all (audio) hardware specific things are handled within portaudio. On the other hand we waste performance and depend on what portaudio does or allows us to do.
I once thought about using Pd 0.37 on IRIX but I resited to try that because portaudio for IRIX (which is used in Pd 0.37) uses a audio API that has been declared obsolete by SGI (and portaudio support for SGI is declared beta!). The new API is much more flexible and it was quite easy to implement it into Pd 0.36. So in this case the use of portaudio is a mayor step back. Okay, here's the good part of the story: on Windows it brought us ASIO support in Pd. So in the end I don't know what to do. But at least on IRIX I'll stick to Pd 0.36 as long as I can!
Olaf
Hallo, Olaf Matthes hat gesagt: // Olaf Matthes wrote:
mattn-l@rogers.com schrieb:
i have too much on my plate right now to rip all the portaudio out of pd and replace it with straight CoreAudio calls. but that's what someone needs to do...
Yes, I think so too. So the question is whether it's worth to use portaudio in general or not. Looking at the sources it seems that since the introduction of portaudio into Pd we got at least one additional audio buffer (and thus additional latency) for each input and output. I know that portaudio makes it easier to develop Pd beacuse all (audio) hardware specific things are handled within portaudio. On the other hand we waste performance and depend on what portaudio does or allows us to do.
I'm not sure, but as I see it, Pd does not use Portaudio in callback mode, but the blocking in/out Pablio backend of PortAudio. IIR Pd could stay with PortAudio, but could get much lower latencies by converting the sound system to be callback based. This OTOH might require large changes to Pd.
Ripping PA out of Pd is not a good idea IMO. It will lead to the cross platform mess we had before and that PA is trying to solve.
ciao
Frank Barknecht _ ______footils.org__
On Sun, 16 Nov 2003, Frank Barknecht wrote:
I'm not sure, but as I see it, Pd does not use Portaudio in callback mode, but the blocking in/out Pablio backend of PortAudio. IIR Pd could stay with PortAudio, but could get much lower latencies by converting the sound system to be callback based. This OTOH might require large changes to Pd.
I'm not sure if changes would be really that big, the callback based implementation is quite easily doable (and has been done already), then there are some critical points that are in need of threading, like soundfile loading, patch opening, and the array drawing stuff (which in need of a redesign anyhow), gui communication.
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Sun, 16 Nov 2003, Frank Barknecht wrote:
I'm not sure, but as I see it, Pd does not use Portaudio in callback mode, but the blocking in/out Pablio backend of PortAudio. IIR Pd could stay with PortAudio, but could get much lower latencies by converting the sound system to be callback based. This OTOH might require large changes to Pd.
I'm not sure if changes would be really that big, the callback based implementation is quite easily doable (and has been done already), then there are some critical points that are in need of threading, like soundfile loading, patch opening, and the array drawing stuff (which in need of a redesign anyhow), gui communication.
Am I understanding this correctly: *If* Pd was converted to callbacks *then* those things you pointed out would be in need of threading (because they are not "realtime safe", as the Jack folks would put it)?
So using blocking IO (Pablio) lets us get away with doing those non-realtime safe things kind of inside the dsp loop at the cost of having large(r) latencies?
Just asking to get a clear view here...
ciao
Frank Barknecht _ ______footils.org__
On Mon, 17 Nov 2003, Frank Barknecht wrote:
Am I understanding this correctly: *If* Pd was converted to callbacks *then* those things you pointed out would be in need of threading (because they are not "realtime safe", as the Jack folks would put it)?
So using blocking IO (Pablio) lets us get away with doing those non-realtime safe things kind of inside the dsp loop at the cost of having large(r) latencies?
Just asking to get a clear view here...
Yes, exactly. For the JACK case this is needed, otherwise the jackd would kick pd out of its chain. We only "fool" JACK into making it believe that we can meet the deadlines in all circumstances, while in reality we can't.
For Portaudio this might be different, and using the callback solution might be an option without further changes. mhm, just thinking what Joe does with his VST version of Pd. Ideally this should be callback based too.
Guenter
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
At 11:50 AM 17/11/2003, guenter geiger wrote:
On Mon, 17 Nov 2003, Frank Barknecht wrote:
Am I understanding this correctly: *If* Pd was converted to callbacks *then* those things you pointed out would be in need of threading (because they are not "realtime safe", as the Jack folks would put it)?
So using blocking IO (Pablio) lets us get away with doing those non-realtime safe things kind of inside the dsp loop at the cost of having large(r) latencies?
Just asking to get a clear view here...
Yes, exactly. For the JACK case this is needed, otherwise the jackd would kick pd out of its chain. We only "fool" JACK into making it believe that we can meet the deadlines in all circumstances, while in reality we can't.
Could anything be done to improve this? Or would this also mean other major rewrites elsewhere?
Luke
Luke Yelavich AudioSlack Founder and head package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com luke@audioslack.com
Hallo, Luke Yelavich hat gesagt: // Luke Yelavich wrote:
At 11:50 AM 17/11/2003, guenter geiger wrote:
Yes, exactly. For the JACK case this is needed, otherwise the jackd would kick pd out of its chain. We only "fool" JACK into making it believe that we can meet the deadlines in all circumstances, while in reality we can't.
Could anything be done to improve this? Or would this also mean other major rewrites elsewhere?
I'd love it to have a kind of Low-Latency-TODO-list for everyone to work on.
And what about dsp externals? They shouldn't be allowed non-reatime safe taskes inside their signal functions as well, should they?
ciao
Frank Barknecht _ ______footils.org__
At 08:13 PM 17/11/2003, Frank Barknecht wrote:
Could anything be done to improve this? Or would this also mean other
major
rewrites elsewhere?
I'd love it to have a kind of Low-Latency-TODO-list for everyone to work on.
And what about dsp externals? They shouldn't be allowed non-reatime safe taskes inside their signal functions as well, should they?
This could get a bit messy I guess. I don't really know much about real-time programming, but I dare say having dynamically linked libraries in the way of this may be a problem.
Luke
Luke Yelavich AudioSlack Founder and head package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com luke@audioslack.com
Frank Barknecht schrieb:
And what about dsp externals? They shouldn't be allowed non-reatime safe taskes inside their signal functions as well, should they?
Since Pd is not threaded _nothing_ should take an unpredictable amount of time. There are several places where these criteria is not met in Pd: data exchange with the GUI, netsend / netreceive objects (blocking network calls), soundfiler object, some CPU intensive array drawing stuff and some more. It's quite important to note that even control (non-tilde) objects can take too long to complete their calculations. That's usually not an issue because these objects are only used from time to time (i.e. not in every DSP cycle) but when aiming for low latencies we'll sooner or later run into problems here....
Olaf
-
Frank Barknecht -
guenter geiger -
Luke Yelavich -
mattn-l＠rogers.com -
Olaf Matthes