OSX + Live Audio Performance

Discussion of music production, audio, equipment and any related topics, either with or without Ableton Live
fishmonkey
Posts: 4135
Joined: Wed Oct 24, 2007 4:50 am

Re: OSX + Live Audio Performance

Post by fishmonkey » Sat Nov 01, 2014 11:35 am

Stromkraft wrote: How is it relevant for the "audio system" that several scenes are launched? Sounds more like a bug to me than something to expect. If you load the CPU too much, OK, but if not? I acknowledge the real time factor, but what is the difference starting up tracks or playing them, you mean?
if the CPU load is low, and glitches are occurring then audio processing is being interrupted for too long. there are many things that can cause this.
Stromkraft wrote: That's good thinking on analyzing latency. But you've heard of OS X Developer Tools and Instruments (that Ansolas just mentioned), right? There's some interesting thoughts on this area here in the Ableton Tech Resource blog.
the discussion on that blog page, which is scraped from another forum, is pretty confused.

the concept of DPC latency doesn't directly refer to the achievable round-trip-latency, although of course it may affect it. the various Windows DPC latency checkers are used to test a system for interrupt spikes, often caused by badly written drivers, e.g:

http://www.thesycon.de/deu/latency_check.shtml
http://www.resplendence.com/latencymon

i haven't use those OS X dev tools much, but i don't believe they will do the same kinds of tests as the two Windows apps that i linked to above...
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Sat Nov 01, 2014 11:39 am

ansolas wrote: Besides that, I think I mentioned somewhere above tht I only had issues with LIVE not Other DAWs
What do you think about Intel speedstep? Could Live do something that kicks this going? I read at least one reference to it and latency in OS X.
Make some music!

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Sat Nov 01, 2014 11:41 am

fishmonkey wrote:
if the CPU load is low, and glitches are occurring then audio processing is being interrupted for too long. there are many things that can cause this.

… the various Windows DPC latency checkers are used to test a system for interrupt spikes, often caused by badly written drivers, e.g:

i haven't use those OS X dev tools much, but i don't believe they will do the same kinds of tests as the two Windows apps that i linked to above...
I certainly think that developers can test for interrupt spikes (or whatever can be considered equal in effect) on OS X. I'm going to ask one music app developer about this. Are there OS X developers we can ask on this forum? If developers can do it, hopefully so can we.

"Many things" can be tracked down and labeled usually.
Last edited by Stromkraft on Sun Nov 02, 2014 12:49 am, edited 1 time in total.
Make some music!

ansolas
Posts: 379
Joined: Wed Feb 27, 2013 11:01 pm
Location: Earth ~ Europe ~ Germany ~ Cuxheaven

Re: OSX + Live Audio Performance

Post by ansolas » Sat Nov 01, 2014 7:26 pm

A frriend of me talked to u-he regarding dropouts, he answered that he use these xcode instruments, thats where I had this info from. Regarding DPC, it is a Windows only thing and has nothing to do with OSX as far I got to know.
i disabled this Intel speed step (which you cant on a Mac)

As resume so far, removing all Max Midi Effects and freezing / resampling All Serum instanced reduced the CPU load that much tht I do not experience any glitches even at 256samples which results into 7ms lateny... Nice. something else interesting:
I tried setting the Samplerate to 88,2kHz , 512samples which also results at around 7ms.
Even tho the CPU load was higher I had no dropouts.

As far as I discover more into depth I let you know.

fishmonkey
Posts: 4135
Joined: Wed Oct 24, 2007 4:50 am

Re: OSX + Live Audio Performance

Post by fishmonkey » Sat Nov 01, 2014 11:27 pm

Stromkraft wrote:
fishmonkey wrote:
if the CPU load is low, and glitches are occurring then audio processing is being interrupted for too long. there are many things that can cause this.

… the various Windows DPC latency checkers are used to test a system for interrupt spikes, often caused by badly written drivers, e.g:

i haven't use those OS X dev tools much, but i don't believe they will do the same kinds of tests as the two Windows apps that i linked to above...
I certainly think that developers can test for interrupt spikes on OS X. I'm going to ask one music app developer about this. Are there OS X developers we can ask on this forum? If developers can do it, hopefully so can we.

"Many things" can be tracked down and labeled usually.
in an OS X context, this is what i'm talking about:

https://developer.apple.com/library/mac ... mance.html

on Windows, DPC means Deferred Procedure Call:

http://en.wikipedia.org/wiki/Deferred_Procedure_Call
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Sun Nov 02, 2014 12:30 am

fishmonkey wrote:
in an OS X context, this is what i'm talking about:

https://developer.apple.com/library/mac ... mance.html
You got some nerve bringing accurate technical documentation into the discussion! Ehm, thank you! That was interesting reading. I do contend this area can be understood (to a reasonable extent) and therefore probably is understood in variable degrees by music app developers. Not that every developer has knowledge about all levels, but I doubt that is strictly necessary.

What is necessary are feasible methodologies to analyze and resolve latency (and audio quality when that is affected) issues. I usually rely on the good ol' replacing one part at a time if I can. Of course when you're down to individual settings or drivers you're reaching a level of granularity where you're likely need to peek inside processes to learn more.

Hopefully, in a forum like this when the discussion is fruitful some actual knowledge can be found and shared.
Make some music!

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Sun Nov 02, 2014 12:52 am

ansolas wrote: i disabled this Intel speed step (which you cant on a Mac)
Up until Snow Leopard and Core2Duo you could use Coolbook for that I think. I'm not sure how often this is likely to be a factor with issues like this.

The issues I've had myself are load issues that is hard to see the cause of. Something like Speedstep could be a factor* in the cases I've had with audio needlelength dropouts and relatively low CPU load. Interestingly reducing the load in Live worsened the problems for a while and if just waiting then there were no more issues while playing.

It's possible I've learnt how to adapt my projects because I've seen much less of this lately.



*I've heard very little about this but have seen references that Speedstep or similar have been in Intel processors since Core2Duo.
Last edited by Stromkraft on Sun Nov 02, 2014 1:01 am, edited 2 times in total.
Make some music!

fishmonkey
Posts: 4135
Joined: Wed Oct 24, 2007 4:50 am

Re: OSX + Live Audio Performance

Post by fishmonkey » Sun Nov 02, 2014 12:57 am

the problem for Live is that it also has relatively strict soft real-time limits, because it is designed to allow you to modify your set on-the-fly in real-time. that in turn causes the several things that drive people crazy: performance unpredictability as a set changes, higher CPU overhead, multiprocessing limitations, and far greater sensitivity to system glitches that linear DAWs are far more tolerant of...
Last edited by fishmonkey on Sun Nov 02, 2014 1:14 am, edited 1 time in total.
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Sun Nov 02, 2014 12:59 am

fishmonkey wrote:the problem for Live is that it also has relatively strict soft real-time limits, because it is designed to allow you to modify your set on-the-fly in real-time. that in turn causes the several things that drive people crazy: performance unpredictability as a set changes, higher CPU overhead, and far greater sensitivity to system glitches that linear DAWs are far more tolerant of...
Which is kind of ironic, isn't it?
Make some music!

alltomorrowsparties
Posts: 116
Joined: Sat Jul 19, 2008 9:52 am
Location: Ireland

Re: OSX + Live Audio Performance

Post by alltomorrowsparties » Sun Nov 02, 2014 5:32 am

The conversation is interesting between you guys, but you need to be careful when comparing performance in Abe with other DAW's.
For instance, Logic has an (unconfirmed) playback buffer of 512 samples regardless of what your i/o buffer is set to. This makes perfect sense as the only time you really need a 32 or 64 buffer is for i/o (read:recording Audio/playing instruments)

Breaking that down even further, one needs to be careful about comparing Abe's session view with arrangement view. Arrangement view seems to operate similarly to how Logic operates. I've seen comparable plugin counts to logic using Abe's arrange window. Again this makes perfect sense. Why allocate 64 samples to processing a track that's playing back (ie NOT being recorded)

Not so for session view. It's always worth remembering this when discussing Abe's performance vs "x"

Edit: If you're going to compare performance of Live with other DAW's, it's always worth recording your session into arrange, deleting all scenes/clips, unarming all tracks and taking a little look around the i/o's per channel to see if there's not any funny live inputs being routed around the place as Live will look on these as critical record armed tracks. These can be especially draining on CPU if they're being sent off on Auxes.

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Sun Nov 02, 2014 6:17 pm

alltomorrowsparties wrote:The conversation is interesting between you guys, but you need to be careful when comparing performance in Abe with other DAW's.
For instance, Logic has an (unconfirmed) playback buffer of 512 samples regardless of what your i/o buffer is set to. This makes perfect sense as the only time you really need a 32 or 64 buffer is for i/o (read:recording Audio/playing instruments).
It has already been suggested to use 512 samples as a baseline to be able to compare in any meaningful way. It was also suggested Live does much more real-time than other DAWs. So this is in the discussion already, I think.

To some extent comparisons are not relevant to solving latency issues in Live 9. I couldn't care much less about how other DAWs perform other than acceptable baselines for what to expect when it comes to performance.
Make some music!

alltomorrowsparties
Posts: 116
Joined: Sat Jul 19, 2008 9:52 am
Location: Ireland

Re: OSX + Live Audio Performance

Post by alltomorrowsparties » Sun Nov 02, 2014 7:34 pm

Stromkraft wrote:
alltomorrowsparties wrote:The conversation is interesting between you guys, but you need to be careful when comparing performance in Abe with other DAW's.
For instance, Logic has an (unconfirmed) playback buffer of 512 samples regardless of what your i/o buffer is set to. This makes perfect sense as the only time you really need a 32 or 64 buffer is for i/o (read:recording Audio/playing instruments).
It has already been suggested to use 512 samples as a baseline to be able to compare in any meaningful way.
I missed that part sorry it's a long thread. The baseline 512 buffer is a good start. Session will still eat up more resources than arrange so deleting clips and scenes in session view and using the arrange will yield an *even* more meaningful comparison if anyone's interested.

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Mon Nov 03, 2014 1:46 am

alltomorrowsparties wrote:The baseline 512 buffer is a good start. Session will still eat up more resources than arrange so deleting clips and scenes in session view and using the arrange will yield an *even* more meaningful comparison if anyone's interested.
Are you certain that deleting clips will free resources when playing back the arrangement? I have never experienced anything else than that session clips not being played in arrangement adds absolutely nothing to the resources used (unless played of course). I view session as containing original clip building block resources and being my mixer.
Make some music!

alltomorrowsparties
Posts: 116
Joined: Sat Jul 19, 2008 9:52 am
Location: Ireland

Re: OSX + Live Audio Performance

Post by alltomorrowsparties » Tue Nov 04, 2014 8:52 am

Stromkraft wrote:
Are you certain that deleting clips will free resources when playing back the arrangement?
Certain NO. Pretty sure YES. Depending on the session, deleting scenes and switching to arrange will free up resources for me. (I know of at least one other guy who I talked to who experiences this too) Whilst I'm pretty sure that Abe's arrange doesn't go "full logic" (ie I don't think it changes the playback buffer to 512 or 1024 samples) deleting scenes does seem to help processor load.

Just because you're playing back from Arrange does not mean Abe won't be allocating resources to session as scenes in session view are playable at any time and will therefore need to be primed for triggering. This is especially true for 1- Any track which is being live monitored (especially instruments) 2- One shot and Un-synced sequences 3- Ableton may reasonably expect a real time tempo change at any moment and has to allocate resources to that. 4- If you've got auto arm functionality on. (i understand all those are not necessarily specific to session but there may well be things going on under the hood that we don't know about and/or more resources allocated to these things due to their real time nature)

Further, not only is eveything primed for playback, but you also have a whole nuther page (the arrangement) which may be playing back stuff too.

So all that adds up.

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: OSX + Live Audio Performance

Post by Stromkraft » Tue Nov 04, 2014 12:59 pm

alltomorrowsparties wrote:
Stromkraft wrote:
Are you certain that deleting clips will free resources when playing back the arrangement?
Certain NO. Pretty sure YES. Depending on the session, deleting scenes and switching to arrange will free up resources for me.…deleting scenes does seem to help processor load.

Just because you're playing back from Arrange does not mean Abe won't be allocating resources to session as scenes in session view are playable at any time and will therefore need to be primed for triggering. This is especially true for 1- Any track which is being live monitored (especially instruments) 2- One shot and Un-synced sequences 3- Ableton may reasonably expect a real time tempo change at any moment and has to allocate resources to that. 4- If you've got auto arm functionality on.
Well,
I suppose this depends on how you work. Obviously, if you actually use resources they will need CPU. But used resources need CPU in arrangement too. A device on a track not playing in arrangement exists there as well. If you delete its clips should not make a difference. Inactivating the devices should have significantly larger impact.

I don't live monitor tracks I don't use and I deactivate devices on tracks I'm not interested in using for the moment for that reason. I don't use auto-arm very often.

I still contend that a track not playing in arrangement with inactivated instruments and plug-ins doesn't use a noticeable amount of resources and if they do I'd consider that a bug. Some memory and some cycles are likely used as you say, but the effect of that should be minimal and of little consequence.

Your notion is still interesting enough to warrant some testing and I must assume there is some use cases where what you suggest would seem important, like when you're prevented from deactivating devices on a track for some reason. But clips?
Make some music!

Post Reply