Performance BETTER when Ableton NOT foreground window - why?

[jim-adams]

I have my new MacbookPro laptop and putting Ableton through its paces to make sure I can render several sounds at once LIVE in real time without hitting the CPU/Memory/Disk wall on my sleek new machine (2.4Khz i5, 256GB/SSD, 8Gig) - not the ultimate but should hopefully suffice for maybe up to 6 layered sound (I'm using SampleTank 3 sounds mostly, a couple native Ableton sounds).

So, I'm at first disappointed as, after laying only two or three sounds, I get the tell-tale crunchy sound of failure to keep up. So, I jump over to the Mac Activity monitor and see that the CPU is fine, plenty of headroom, and same for Memory, etc.. Here's the interesting thing, and my question - I've found that with even SIX layered keyboard sounds and when playing hard, when I get the 'crunchies' while Ableton Live is the foreground app - as soon as I switch the foreground to something else (e.g. Activity Monitor) - the sounds play absolutely perfectly with nary a glitch. Wha?

So, I pose the question to this esteemed panel - why?

Thanks!
Jim

[su]

I've noticed that I'm more likely to get "the crunchies" when parts of the Ableton interface or a vst interface are highly animated - e.g. meters moving, knobs moving, sliders moving, other kinds of animation. I can sometimes make the crunchies go away by minimizing windows in which there's a lot of animated gui elements.

[jim-adams]

Perhaps there is (or should be) a setting in Ableton to 'de-prioritize graphics' so they don't - ridiculously - murder the audio in favor of clean meters.

Known setting?
thanks again
Jim

[T0n1]

Live - as any real time software application - already has thread priority management built in. I don't know anything about the VST or AU API, but for M4L, I can testify that it is the responsibility of the device developer to use "deferlow" objects where appropriate, as e.g. incoming MIDI messages are executed in the high priority thread to minimize latency, and neither Max nor Live can formally infer which execution steps of the patch aren't part of the time critical "finger->controller->Live->audio->air->ear" chain.

Hiding graphical objects inapproprietaly executed in the high priority thread has the effect that the underlying OS will immediately return from the call instead of lavishliy rendering them.

If interested, you can read about the complexities of event priority management in Max/M4L here: http://cycling74.com/2004/09/09/event-p ... -vs-queue/

[oblique strategies]

Mac OS X:
So if one uses the 'Hide' option (Command-H) will this also effectively reduce the system resources required to render the Live GUI?

How about minimizing the Live window into the Dock?

And, if one still wants to see the Live window:
Does the Arrange view require less resources to draw moving knobs than the Sessions view?

I use many M4L LFOs to control Live Aux Sends for spatialized audio, so there are a lot of moving knobs in my Session view!

[jim-adams]

Again, my desire is to vet my brand new MacbookPro retina (a cheaper one, 2.4khz 256gb SSD, 8gb ram etc.) w.r.t handling a serious onstage workout...

Regarding "finger->controller->Live->audio->air->ear" post, I appreciate that - let's just say - essential code is executing. But, did you not miss my question altogether? That same code executes - i.e. the sounds are generated - in both scenarios: a) when Live is foreground, and b) when it isn't. There the question is: why is the same midi>ear processing so much more performant (less glitchy) when Live is in the background?

The obvious (I'm inclined to think) conclusion is that it has nothing to do with the implementation of the essential midi>audio>ear chain (as that occurs in both cases) and more to do with the active window getting too much preferential treatment by the OS in handing out CPU cycles. This leads me to my curiosity in any setting in Live that de-emphasizes (deprioritizes) the GUI in favor of the audio engine.

I noticed also, that "scraping a window over Live" (forcing a lot of GUI activity) also created a ton of audio glitches (while playing with one hand).

I was about ready to pack up my MacbookPro (within 14 days of purchase) and go for a 2.9kz processor, but the CPU reading still stays (while Activity Monitor is foreground - Heisenberg, anyone?) that it's not even breaking a sweat (less than 50% cpu used, little 'memory pressure')

Now, as I was adding keyboard sounds in the brand new SampleTank3 plug-in, and IT was in the foreground along with Live - maybe our friends at IKMultimedia have some culpability here.

I'll report back later on that front!

-Jim

[pencilrocket]

Yosemite just sucks? Get other OS.

[T0n1]

To clarify things up regarding priorized event scheduling and CPU resources in general: High priority threads regularly interrupt low priority threads, for audio with a frequency of sampling rate divided by buffer size, e.g. for 44.1kHz / 256 samples you get a frequency of roughly 172Hz. Each time around a plugin processes its buffer sample by sample, emptying the input buffer and filling the output buffer. When finished, it becomes idle and frees the CPU for other tasks.

Low priority threads used for things like GUI drawing can only perform their tasks in the idle time between these cycles. If the CPU is at its limit, the graphics will stutter because it gets interrupted by the high priority threads before finishing its task, but the audio will fluently continue. So in general there is absolutely no need to worry about too much stuff going on on the screen.

With M4L, I had problems with crackles when receiving a high priority event (e.g. MIDI CC in) and forgot to "deferlow" side actions not immediately related to audio to the low priority thread in the patch. Regarding GUI feedback, as far as I know Max/M4L objects encapsulate this deferlow calls internally.

But if you use 3rd party plugins, you're relying on the plugin developers not to directly call OS GUI routines on a high priority thread, but any details on that diverge heavily between OSes and the concrete GUI library used. Hiding GUI windows is just a workaround for such problems. If you're on OS X with Live, you often have the luxury of choice between the VST and AU variant of the same plugin, sometimes one performs smoother than the other (e.g. crackles due to parameter automation), depending on the experience and expertise of the developers for each system.

[oblique strategies]

I have experienced both the stuttering GUI, & VST/AU performance discrepancies.

I recall one harrowing performance where my GUI actually froze while the music played. I couldn't do anything but wait it out! Fortunately the GUI stuttered back to life, & I switched scenes to one with fewer clips. This episode didn't last long & the audience didn't have time to become aware of the problem, but it felt like a long time to me. I was sweating bullets wondering if my computer was going to crash or if I'd eventually try pressing the spacebar to stop it.

[fishmonkey]

because OS X and Windows are multitasking operating systems, there is never any guarantee that a process will get the resources it needs to work without glitches. one badly written piece of code that hogs the CPU for too long is enough to cause a glitch, no matter how powerful your machine is.

and playing and processing audio without glitches is one of the most demanding tasks...

there is some info on how Live prioritises stuff here:

https://www.ableton.com/en/manual/compu ... trategies/

[GFast]

Regarding the " Wed Aug 06, 2014 3:45 pm " posting, I too am getting this....when Ableton is in the background, with any other app (a browser, MS Word, whatever) in the foreground, the audio crackling starts. But w/ Ableton in the foreground (WIndows 11), no crackling.

I have a crazy powerful laptop, and have done deep digging (w/ throttlestop, etc), and my projects are not big hogs at all (the CPU meter rarely goes over 20%), and yet, just pop a window in front of Ableton, and within X time, audio crackling starts. Crazy.

I know this original thread was from 8 years ago, but if by chance anyone has any recent suggestions directly related to Ableton not in the foreground, and how to give it higher priority CPU threads in such a case (or perhaps, by telling Ableton to not waste CPU on moving meters, etc), I am very eager to figure this out.

all the best