[Fwd: Re: SERVER FAILURE with SC 3.6.6 on OSX 10.9.5]

Arthur Sauer

2014-10-09 11:07:55 UTC

I'm willing to help solve this problem, so any pointers are welcome. I
guess I should start with an XCode build on the Mac?

That?s very kind, the more so as so seem to be in the middle of show
preparations!

I'm actually starting the second half of a 5 month tour :)

We seem to need this kind of real world scenario to
demonstrate how disastrous the effects of AppNap can be for SuperCollider.
Let?s hope that for the sake of this discussion your problem *is* the
AppNap-Trap (your findings seem to be so contradictory that one starts
doubting again. So Sherlock Holmes mode on :)).

I'm beginning to have the same doubts.

The only process that gets inhibited as far as I can tell now, is that a
sample won't play.

I think the most reliable
way to verify that we actually are dealing with AppNap, is to press the
Dock-Icon of the napping sc-component (as seen in Activity Monitor)
*during* an ongoing process that is assumed to be inhibited/slowed down by
AppNap and see if anything changes to the good. That might often not be
possible, but sometimes it is, and in that case you have a positive that
AppNap is involved.

I'll try that again later today.

(?Scide" seems to be represented by the
?SuperCollider" process in Activity monitor (hopefully it?s not more
complicated than that).

OK. I don't think this would have anything to do with my problem.

After the prologue let me say this first: it is likely that some of the
people who could help are not reading this thread because it?s on SC-User.
This is actually an SC-Dev issue, and the other space where people are
listening is Github. So I think you should consider ?escalating? :) the
issue.

I've been thinking about that as well.

If Github, the thread to go is this one (Snickell, the author of
https://github.com/supercollider/supercollider/pull/1011#issuecomment-5828
8403
Among others you will see a brief discussion for which components of SC
AppNap should be prevented. SC-Dev is a good place too, more OSX-people
are likely to listen there, but I am not sure if Snickell is listening
there, who is very helpful. Unfortunately the group of people interested
in the maintenance of SC is split over four places that only partially
overlap.

What is the fourth place: private communication? (I see SC-dev, SC-users,
Github issues, and...
it is.

If Logic is in the foreground and I play a loop, nothing happens. If I
stop Logic and click on a note, I might hear something. Then once it
stops
reacting, it will not come back.
If I send a ProgramChange from Logic, it is received.
If I send a ProgramChange from another window in SuperCollider to the
same
IAC-bus that I use for Logic, no ProgramChanges are received.
the App Nap of SuperCollider switches on and off all the time.

But not sclang, right.

Yes.

That would show that the patch is helping. (scsynth
never napped, even in the past, it seems to be a process recognised as
time-critcal by the OS automatically). In theory it should not matter if
scide takes a nap, as it should be independent of the communication going
on with sclang and scsynth, but maybe that needs more consideration. Your
finding shows that the patch does not cover whatever is represented by
?SuperCollider?. Again in theory this might not be a problem, but your
findings make it likely that it is.

Likely, but NOT 100 % shure.

I Use an RME UFX interface and the TotalMix FX also had the App Nap on.
I
decided to turn it off, and I get the same effect: App Nap turning on an
off.
So it is not just only SuperCollider showing this behaviour.

Right, AppNap is intended behaviour aimed at saving energy. The point is
to prevent AppNap for processes that are time-critical. OSX recognises
some processes automatically, others must express their wish not to be
sent to bed explicitly.

That's right.

This is a version that has no App Nap checkbox in the Get Info Window.

I think the AppNap-switch in the info-box should appear for all
applications not built with SDK 10.9.

That is what I suspect but have not yet tested.

But there is (or used to be) this
confusing factor that if an Application is already registered in the
system with a specific AppNat-status, that status does not change,
although you install a different version of the App, and you don?t get a
choice in the GUI any more. So if you ever had an Application installed
that was build using SDK-10.9, OSX thinks this Application knows what it
is doing with respect to AppNap and does not offer the switch any more,
even if you install a different version.

I will test this to see what happens.

But you can change the AppNap status on the command line with
defaults write <app domain name> NSAppSleepDisabled -bool YES
as described for example here
http://cobbservations.wordpress.com/2013/11/05/disabling-app-nap-in-os-x-m
avericks/
Command-line/Info-box-switching of AppNap-status works on application
level - one might prefer a more fine tuned behaviour as SC consists of
several sort of independent processes.

I agree. I will test the commandline after testing what will happen when
building with 10.8 as a target.

.. which was built from commit 24298ffa41068cf235dc60cafec4ea5b93aaad63
and App Nap is not switching on and off... App Nap is off.

So you are really saying no AppNap in a build without the AppNap patch?

Yes.

latest OSX recognises privileged Applications better and prevents SC from
napping automatically.

Could be, but my conclusion is that whatever changed, did not change the
behaviour for the better.

Another explanation would be that AppNap-rules from
an older install are cached somewhere and are still active although you
installed another version.

Is worth the check.

Or some processes on your system interact with
SC in a way that prevents AppNap.

Not likely, since then it should happen with all versions I've build.

Exclude the impossible and you will
embrace truth :) Hopefully somebody that understands these things
technically will have an idea...

Getting more curious, I opened the 3.6.6 version (a version I downloaded
without building it myself), AFTER disabling 'Prevent App Nap' in the
Get
Info Window. This is the original version I used for the show.
And lo and behold: after keeping the scide in the foreground for some
time, App Nap does not turn off for sclang, nor for the scsynths and not
for SuperCollider.

Hmm, *maybe* the explanation is like the one above. Once the system knows
how to deal with SuperCollider it keeps that setting. But probably not - I
did see the symptoms of AppNap returning after using a master-vanilla
build without the patch on my system. So this needs more research? But you
keep having your problems communicating from Logic, right? So the patch or
any OSX-cleverness do not cover the case that ?SuperCollider" is accessed
from outside - I can confirm this. In my build including the patch the
?SuperCollider? process also naps if in the background, but sclang stays
awake. The question remains if this causes problems to processes going on
with sclang and scsynth. I always had SuperCollider in the foreground in
my experiments back then, so I didn?t meet that use case.
All the best, please keep communicating on this issue, we need a robust
solution for the AppNap problem. And we probably have to seek help from
people not seeing this thread.

I will.

I have to go now, but will come back to it later today.

Best regards,

Arthur

Best
Rainer

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/