Re: Working on OS X

On Fri, Apr 3, 2009 at 11:50 PM, Jack O'Quin <[email protected]> wrote:

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

Heh its safer for me to assume that those that programmed this know a good
deal more about it than I do,:)

>
> > 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.
>

Yea I haven't quite nailed down what is causing it yet.  I did just confirm
that I was running with period sizes of >2048 frames per period however when
I was doing my earlier testing.  Just to confirm though I went ahead and set
my frames per period to 512(On CoreAudio it seems to be locked on 3 periods
per buffer in QJackCTL at least).  I saw no difference in what I was
experiencing, either with -t or without.  Without -t(And with -T) I did get
some debugging output though that has me wondering if maybe the
get_sched_param isn't returning correct values and screwing things up
slightly....

jamin trace [44207734]: buffer size is 512
> jamin trace [44207737]: latency due to I/O Buffering is 0 frames.
> jamin trace [44229542]: new DSP state: 02.
> jamin trace [44230331]: JACK realtime priority = 0
> jamin trace [44230331]: DSP realtime priority = -1
> jamin trace [44230336]: DSP thread created
> jamin trace [44230336]: latency due to I/O Buffering is 0 frames.
> jamin trace [44230338]: DSP thread start
> jamin trace [44230338]: new DSP state: 04.
> jamin trace [44420049]: shutting down I/O and DSP
> jamin trace [44420049]: new DSP state: 020.
> jamin trace [44420050]: DSP thread wakeup
> jamin trace [44420050]: DSP thread end
> jamin trace [0]: new DSP state: 040.


Namely the JACK realtime priority returned seems to me to be off(Shouldn't
it be in the realm of 90+), though I could easily be very wrong.  As a
result the DSP thread is being created with even lower priority and screwing
things up.  Of course this is all still using the POSIX API which if I am
reading Apple's docs right can't be used to create a realtime thread
anyways, you have to use their MACH calls.  Again it is very easily possible
I am wrong, but I wanted to see if someone here could confirm it or if
someone could tell me I am crazy stupid:)


>
> 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.
>

Yea, that was my concern upon looking at the code, and why I have been
holding off on attempting to implement any MACH threads, as I ams ure there
are things I am missing that are going to give me a headache;)


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
>

Heh no rush, I am working on this in my sprae time when not working on other
projects so I will probably be moving even slower than my normal programming
speed, which I am pretty slow at anyways:)  Again the help is appreciated.

       Seablade

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

_______________________________________________
Jamin-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jamin-devel