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:)
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.
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.
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
before long.
Seablade
On Fri, Apr 3, 2009 at 10:58 PM, Jack O'Quin <jack.oquin@...> wrote:
> 2009/4/1 Thomas Vecchione <seablaede@...>:
> > Howdy folks-
> >
> > I am currently working on getting Jamin running native on OS X using
> > GTK-OSX. I already have it compiling and running, and even packaging in
> a
> > .app(I think I am basing my work off .95 for the time being IIRC, I will
> > update as needed once I can get that working, can provide a patch as
> > desired). However I am running into some performance problems that I am
> > having difficulty troubleshooting and wanted to see what the opinions are
> > around here. First let me describe the performance I am seeing....
>
> I have not looked at that low-level I/O code in many years. But, I
> think getting it working on OSX is possible and desirable.
>
> > Currently Jamin opens and runs fine. However the moment it starts
> > processing anything other than silence, the interface becomes very
> > unresponsive. It actually does respond eventually, just usually at least
> 10
> > seconds after it should, so it isn't frozen obviously. If I bypass Jamin
> > via the bypass button, or if I stop playback going into Jamin(In my case
> I
> > am feeding it via Jack from Ardour so I just stop Ardour's transport) the
> > interface responds as normal. So it is usable in a set and forget type
> of
> > situation right now, but obviously that is not the ideal. My CPU is not
> > maxed at any point, Jamin is reported by both top and system monitor as
> > taking about 40% CPU, a bit high, but nowhere close to maxing a my dual
> core
> > processor, and neither core is loaded down beyond about 50% total really.
> > Audio processes fine, and is uninterrupted(no xruns or dropouts).
> >
> > I am going through the code and am wondering a few things, part of this
> is
> > going to show some lack of ability in programming I am sure:) At any
> rate,
> > I can't for the life of me figure out the debugging functionality you
> have
> > in place. If I either provide a -vv (or -v) switch, or manually set the
> > debug_level variable to DBG_NORMAL I still get no additional output here,
> > and I am not completely certain as to why.
> >
> > In particular I am trying to figure out precisely how the DSP thread is
> > created a scheduled as I believe that might explain the problem I am
> seeing
> > above, I suspect that I will need to change this for OS X to use MACH
> > threads after some discussion with others on IRC that would know better
> than
> > me:) But I am not sure if this would still be the case if the DSP thread
> > creation is in fact handed off to Jack to do, but I can't confirm that
> > easily without adding in a lot of debugging output that seems to already
> > exist, I just can't access it:)
>
> Most of your trouble is probably due to the DSP thread. It depends on
> POSIX thread support, which apparently does not work well on OSX.
> Stephane Letz had to replace all the POSIX thread support in JACK-1
> with MACH threads to get things working reliably.
>
> Fortunately, jamin only needs the DSP thread to handle the relatively
> rare case of block sizes smaller than the 256-frame window needed for
> the FFT processing. As long as JACK is running with a period size of
> at least 256, the FFT is done directly in the JACK thread.
>
> Try running jamin with the -t option, which causes it not to create
> the DSP thread. That may solve your problem, at least for normal
> latency settings. There is generally no advantage to low-latency
> small block sizes when mastering, so this is not an onerous
> restriction.
>
> Making it work in with very low latency on OSX using Mach threads, is
> a much more difficult task. I suppose the Mach thread code from JACK
> could be adapted for that purpose. But, I don't recommend fooling
> with that until things are working well for period sizes of at least
> 256 frames. After all, the real problem could be somewhere else.
>
> > So my questions are... how exactly does the debugging output work, and
> > where should it be logging to? And how is the DSP thread creation
> handled
> > by default(Assuming Jack >=.80 as I believe that is the cutoff in
> > config.in). Thanks much for the help, just trying to get a usable
> native
> > .app of this pushed out to use for mastering on OS X.
>
> The trace output is collected in a circular buffer to avoid printing
> in the realtime thread. The -T option causes the contents of that
> buffer to be printed on shutdown. It will only print the last
> TR_BUFSIZE entries. You can make that bigger, if necessary.
>
> You could probably also modify io_trace() in io.c to print the trace
> information directly to standard output. For reasonable period sizes
> that will probably not cause overruns. I was being somewhat pedantic
> about real-time safety when I wrote the original version.
>
> Regards,
> --
> joq
>
|