Re: [Audacity-quality] Bug 1338 and CPU usage on Mac

[Gale A. <ga...@au...>]

There are a lot of Voxengo plugins on their home page:
http://www.voxengo.com/

They are generally well spoken off AFAIK. I wonder if only
SPAN out of their offerings has the subject problem?

Toneboosters Reelbus was reported for the same problem:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1338#c0

so really I think we don't know how widespread the problem
is.

At the moment I think we should tread carefully before
thinking that we could just allow 1338 to re-exist.

1338 probably has more impact than the busy-wait CPU
usage has, even if more people might happen to notice the
latter in Activity Monitor.



Gale




On 24 July 2016 at 23:08, Paul Licameli <pau...@gm...> wrote:
>
>
> On Wed, Jul 20, 2016 at 6:38 PM, Gale <ga...@au...> wrote:
>>
>> Paul Licameli wrote
>> > Open Audacity, dismiss the splash dialog, and open a modal dialog such
>> > as
>> > the Noise generator.
>> >
>> > Observe CPU usage in the Activity Monitor utility application.
>> >
>> > It is near 100% in 2.1.3 and very low in 2.1.2, no different there from
>> > the
>> > idle state of the program.
>> >
>> > So sure enough, reverting the wxWidgets commit
>> >
>> > "backport merging in Václav's fix for getting CPU usage down in
>> > ShowModal"
>> >
>> > to fix the hanging bug 1338 caused this.
>> >
>> > Do we want to accept the bad effects of bug 1338 instead, which would
>> > likely affect far fewer users?
>> >
>> > Or should I do some more research into the MacOs system calls to figure
>> > out
>> > a better fix for the busy wait?
>>
>> Thanks for asking, Paul.
>>
>> I thought you said you felt the 1338 fix was better than no fix, so I
>> didn't really argue. This would be the more so given we don't know
>> why only VOXENGO sufferred from the problem, so it's possible some
>> other plugins are affected.
>
>
> As I said in Bugzilla comments, I made new discoveries today.  The debugger
> stack trace shows that SPAN uses a separate thread, and uses the mostly
> deprecated Multiprocessing API
> (https://developer.apple.com/reference/coreservices/1661795-multiprocessing_services?language=objc),
> which I suspect might not always play nicely with the newer Cocoa based
> stuff that wxWidgets 3 uses.
>
> So my original suspicion that Voxengo SPAN does event handling in an unusual
> way may be correct.  It may be that all the more newly developed plug-ins
> will not use the old Multiprocessing and will not have the same problem.  We
> do not know of any others that suffer.
>
> So is fixing Audacity's interaction with this one plug-in overridingly
> important?  Should we tolerate busy-waits in all modal dialogs just to fix
> that?
>
> I began to have my doubts about this tradeoff, but I think your opinion
> here, Gale, has more weight than mine.  Tell me how popular SPAN really is.
>
> A one-line fix, just reverting one commit in wxWidgets, has that effect.  I
> was trying to find a way to cause the busy-wait, which seems to be the price
> of not freezing, only in case that I can detect the presence of other
> multiprocessing tasks.  But the available online documentation for obsolete
> OSX versions is not always clear or complete.  So far I have succeeded only
> in wasting a Sunday afternoon on this.
>
>>
>>
>> I did not realise the Audacity CPU use would be around 100%,
>> but on my Quad-Core Mac mini I only go from about 10% total
>> CPU to just over 30%.
>
>
> I have a quad core Macbook running 10.10.2, and my Activity Monitor
> sometimes shows more than 100% for some processes, so perhaps my monitor and
> yours use different scales for CPU utilization.
>
>>
>> Once the user presses OK on an effect, the CPU use is the
>> same as what it was applying the effect in 2.1.2. Observe
>> Amplify for example.
>
>
> No surprise there.  It's only the wait for mouse events in the modal dialog
> that makes a busy-wait.
>
>>
>>
>> Preferences would be a case where the dialogue might be left
>> open for a while, so might "Error importing".
>>
>> Perhaps it would be a P3 for the CPU issue? AFAICT OS X 10.7
>> and later requires at least dual core, but 10.6 allows single
>> core. It could be a P2 if we wanted 2.1.3 to be the "best possible"
>> final version for Snow Leopard rather than just "final version"
>> but I could live with P3.
>>
>> Are we stil aiming for 2.1.3 to be final version for Snow Leopard?
>
>
> James said no, do something about accessibility first.  I also am tempted to
> attack this problem, using some of the guidance Leland gave me, off-list.
> But perhaps later than 2.1.3.
>
> I am not caught up in emails about various Bugzilla issues that accumulated
> when I took a short vacation lately.
>
> PRL
>
>
>>
>>
>>
>>
>> Gale
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://audacity.238276.n2.nabble.com/Bug-1338-and-CPU-usage-on-Mac-tp7575201p7575236.html
>> Sent from the audacity-quality mailing list archive at Nabble.com.