Re: Working on OS X

2009/4/1 Thomas Vecchione <[email protected]>:
> 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

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