[PD] dropouts on mac os ...

[james tittle]

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