Re: Working on OS X

On Fri, Apr 3, 2009 at 10:33 PM, Thomas Vecchione <[email protected]> wrote:
> Thanks for the reply-
>
> Hmm pretty certain I am running with period sizes over 256 at the moment,
> but I could be wrong, I will double check that shortly.  I will also try the
> -t option again, though I tried it once when I began suspecting the DSP
> thread creation and scheduling might be my issue, but noticed no difference
> that I could see.
>
> Also based off my observations, yes my strongest suspicion is with the DSP
> thread being the problem as well.  Thanks for the heads up on the -T switch
> though, that will come in handy at least to see the debugging output.  That
> is of course the other reason I didn't want to write my own debug code,
> along with duplicating effort, I figured there was a good reason for what
> yall had done:)

Maybe not a *good* reason,  but there was some rationale at least.

> Part of what is confusing about this is that it seemed to work fine under
> X11 on OS X performance wise, but switching to native GTK-OSX I am definitly
> running across these issues.  However nothing in gprof shows a problem, in
> only one of the 6 most time consuming tasks I think is related to GTK-OSX
> and that is a message dispatch routine for ObjC I believe, and even that is
> not taking up much.  The rest of them are all related to fftw however, but
> as I said, my CPU certainly isn't close to being maxed out.

The GUI and real-time parts of jamin are pretty well separated.  But,
it is certainly possible for there to be some undesired interaction
that causes the problems you are seeing.

> After talking with Paul on #ardour, he pointed me to the Jack Mach Code,
> which apparently is very simple in comparison to the code to get proper
> permissions in POSIX threads(It really is incredibly simple) but it was
> difficult to tell exactly what the thread creation code was or was not doing
> because I couldn't see the debug output.  Once I can be more sure of what is
> going on, I will take a stab at putting MACH thread support in and include
> it in my patch I can forward on to yall(Assuming I get it to patch cleanly
> against a more up to date version of Jamin of course).  The primary other
> changes have to do with removing preprocessor #defines for paths on OS X as
> most of the paths are all contained int he bundle which can be put pretty
> well anywhere on the computer, going off memory anyways, its been a couple
> of months since I did that work.

Even if the MACH thread creation is straightforward, the interaction
of the JACK thread with the DSP thread is quite complex.  Too complex,
in my view.

> I also tend to agree that low latency is not a priority for mastering
> though, so if upping my period size works, I will just add the -t to the
> startup script if I can for the moment until I get a chance to look closer
> at Mach threads.
>
> Again thanks for the help, I am sure I will be back with more questions

I will probably respond more quickly.  Your first message arrived just
as I had returned from a trip.  It took me a while to catch up will
the e-mail backlog.
-- 
 joq

------------------------------------------------------------------------------