On Apr 19, 2006, at 11:19 AM, derek holzer wrote:
fact of the matter is that the Aqua Tcl/Tk GUI on OSX interferes
with audio processing in an entirely unacceptable way. When I want
to do serious PD audio work, I boot Gentoo PPC Linux. Quite a bit
of optimization for video/3d has been done for the OSX version of
PD,. This was mostly for GEM, as PDP and PiDiP remain quite
unoptimized.
...here, of course, you meant to distinguish between "ppc/altivec"
and "x86/mmx/sse/sse2" optimizations, which really have nothing to do
with "osx" vs "linux"...
But audio doesn't seem to be a specialty/priority for the
developers right now. I base this on comments from James Tittle and
others when I brought this issue up before.
...guilty as charged! when I don't get paid to work on something, I
tend to focus on what is important to me: feel free to donate a
bounty if you want better ppc/osx/intel/whatever support: I've got
rent to meet, and like to eat too ;-)
I've also gotten feedback from others on this list that PD+Audio +OSX is on the border between crippled and useless in its current
state.
...again, the distinction is "aquaTk on OSX", which is actually
emulating X11 calls thru quartz emulated Quickdraw API to be
displayed by the aqua window manager...by running "x11Tk on OSX" you
get the same bad performance you live with on linux/x11 (ie. back to
the improper way Tk is used in PD, see archives for further
explication and hand-wringing)...
One suggestion which HC Steiner made (IIRC) is to compile PD
against a Fink or DarwinPorts X11 version of Tcl/Tk instead of the
Aqua one. This entails some makefile buggery which I haven't gotten
around to yet.
...newer versions of the tcl/tk frameworks allow one to compile
against aqua or x11 versions of Tk: perhaps you'll wake up one day
and have this for free? As a veteran linux user, a little makefile
buggery should be unconscious for you by now...
Another suggestion is to make sure that the realtime priority flag
is disabled on OSX with the -nrt flag. This seems to be a
workaround in some cases, but not a solution to the problem.
...yeh, this has been covered elsewhere: basically, it's not a good
idea to promote your application's priority above the window
manager's priority, unless you don't want to actually interact with
the gui :-\
james