Ableton Forum

CPU usage is significantly higher in Live than in other ReWire host when ReWired with Project5. When using a P5 project with only 4 DS864s and ReWired to Live, I get a cpu reading of:

17% from P5's meter

20% from Live's meter

and when P5 is ReWired to Tracktion or Sonar with 4 DS864s:

4% from P5's meter

4% to 5% from Sonar's meter

NA% from Tracktion's meter since it doesn't give a number.

With the Autorun.p5p song that comes with P5 loaded, I get the following from when ReWire to Live:

56% from P5's meter

59% from Live's meter.

and when P5 is ReWired to Tracktion or Sonar with 4 DS864s:

18% from P5's meter

19% from Sonar's meter


It seems strange that P5 has no cpu issue with Sonar and Tracktion, but does with Live. Ableton, please comment on this one.

Thanks

I find the same type of problems with P5 and Live--cpu readings higher than they should be. I've also had some serious problems trying to run fruity loops as a vst in P5 rewired into Live--P5 usually crashed within ten minutes, but while working it sounds like there is something wierd happening due to the tempo being slaved to Live. It sounds like the drum hits in fruity loops are chorused or flanged, but it is inconsistent and comes and goes. I think it has to do with the rewiring. I remember seeing comments here about the next update fixing some rewire issues--can we hope that it will take care of some of this P5 malarkey?

Ryan

It's the buffer sizes!

IIRC,

I'm almost certain that Tracktion & Sonar are using
the preferred size by the audio driver (most likely something
like 3000-4000 samples for DirectSound and probably around
256 for ASIO, depending on the cards) inside their engine.

and that Live use a constant buffer size of 128 or 256
inside their engine whatever the driver/card.

this would make a big difference in CPU usage.

I've monkeyed with all kinds of ASIO 2.0 latency settings on my RME multiface with P5, Live, and Sonar, and I don't think that is the issue. Are you suggesting their that besides the latency on the soundcard I've been adjusting (the buffer size and therefore the latency in ms), there is another buffer in Live and SOnar? Is this buffer adjustable, what is its relationship to the buffer/latency on the soundcard? I'm not sure I follow your comment. In Live it seems like you hardeware setup in the preferences, bringing up you soundcard's settings window, and you adjust from there--i.e. you set it wherever you want, i don't think live makes any choices there. Same type of thing in sonar, though a bit less staight forward--you choose your settings for buffer/latency, and if it clicks and pops you need more. I've found live capable of more at the lowest possible latency on my rig, though both live and sonar work great. The problem we're talking about here is the rewiring of P5 into Live--something isn't happening like it should, and as much as I love Live, I think it has to do with Live's rewire implementation, as Agnishvatta always scientific tests shows in black and white.

Ryan

Depending on how the audio engine is implemented (and that is a decision
that would differ from application to application) there are 2 choices
either you:

a) always use the requested audio driver buffer size inside your engine
(whatever it is) and don't have to worry about managing how to give
it to the audio driver but losing efficiency in your audio engine.

b) use a fixed (usually power of 2) size and have to manage sending
buffer of the requested size to the audio driver but giving you more
efficiency.

I won't get into more details...

I don't think the test is scientific...
I'm almost certain that Sonar+Tracktion use method a
and Live uses method b.

For doing a scientific test, you would need to have
a driver whose preferred buffer size is the same as the
Live internal one.

Believe me, I know what i'm talking about

I don't think the test is scientific...
I'm almost certain that Sonar+Tracktion use method a
and Live uses method b.

For doing a scientific test, you would need to have
a driver whose preferred buffer size is the same as the
Live internal one.

Believe me, I know what i'm talking about

I'm sorry to say this but your wrong! Live is not using a secret internal audio buffer, maybe you are referring to the buffering that Live uses for its disk streaming? I've already proved this to myself using Martin Walker's latency test method:

http://www.sospubs.co.uk/sos/Sep02/arti ... an0902.asp

http://www.sospubs.co.uk/sos/Oct02/arti ... an1002.asp

Live, when using the same audio buffersize, gives the same results as all other host I've tried using ASIO. I did this back in October.

Anyways, why should we believe you? Why do you think your knowledge is so superior? If you know, then tell me whether or not ReWire, as developed by the Propellerheads, uses buffering for its audio streams. Why don't you post something to back up your claims?

Earlier you said:

I'm almost certain that Tracktion & Sonar are using
the preferred size by the audio driver (most likely something
like 3000-4000 samples for DirectSound and probably around
256 for ASIO, depending on the cards) inside their engine.

and that Live use a constant buffer size of 128 or 256
inside their engine whatever the driver/card.

Your telling us to believe you and at the same time your same "I'm almost certain" and "Live use a constant buffer size of 128 or 256". So which one is it, 128 or 256? If it's 256 it would be exactly equal to the 256 that you related to the ASIO support for other host. Your post is almost insult! This cpu issue with ReWire is not good. Ableton so far at least me and Ryan are waiting for Ableton to comment on this.

Hi folks,

our unnamed guest is totally right. The key for the performance of project5 is the buffersize that is passed to Project5 from the ReWire Master. I will call this ReWire-Buffersize for better understanding.

Like already guessed Live currently use a fixed ReWire-Buffersize for that. This ReWire-Buffersize is not directly related to the one from the Audio interface.

Other ReWire Master programs like Sonar, Cubase,... make the ReWire-Buffersize depending on the buffersize of the current selected audio interface.

We'll do this in Live too somewhen but it's not clear at which time. But at least we'll give the possibility to set the ReWire-Buffersize somehow.

But it's also clear, when using Sonar with an audio interface providing a really small buffersize, you'll get a dramatical performance lost in Project5 because in that case the ReWire-Buffersize is also very small.
I tried it with a M-Audio USB Audiophile. With a audio interface buffersize of 80 samples it was not more possible to play Project5 as ReWire slave. With the so called medium latency setting of the Audiophile the performance was in the same range as with Live.

regards,
Alex

amen bro. I have never heard of any sort of secondary buffer in Live or other software, and it just seems impossible that it is some secret that only guest (is "almost certain" he) knows about. Live's buffer and latency ARE the same as my soundcard and there is no variation to that or anything but that, plain and simple.

Ryan

Hi ryan,

please read my posting about the difference between ReWire-Buffersize and audio interface buffersize.

regards,
Alex

Hello Alex,

Other ReWire Master programs like Sonar, Cubase,... make the ReWire-Buffersize depending on the buffersize of the current selected audio interface.

We'll do this in Live too somewhen but it's not clear at which time. But at least we'll give the possibility to set the ReWire-Buffersize somehow.

But it's also clear, when using Sonar with an audio interface providing a really small buffersize, you'll get a dramatical performance lost in Project5 because in that case the ReWire-Buffersize is also very small.
I tried it with a M-Audio USB Audiophile. With a audio interface buffersize of 80 samples it was not more possible to play Project5 as ReWire slave. With the so called medium latency setting of the Audiophile the performance was in the same range as with Live.

I knew there is a ReWire buffer, but I thought it was fixed at 128K in all host. Are you saying that Live uses a static ReWire buffer regardless of the number of channels? That would mean that, if Live uses a 128K buffer, that for all 128 audio streams it would only get that 128K? So with Project5 in other host that would be a total buffersize of 16MB covering all 128 streams. Not sure I get it.

hold on let me try something...

...

...

Okay, I've just tested Live at 10MS and 100MS and the CPU remains the same both times. Alex, is Live using 128 or 256 and is this for all ReWire streams or per ReWire stream?

Sorry Guest, I didn't think you were talking about the ReWire buffer. You made it sound as though audio in Live would be affected as well. Please accept my humble apology.

So Ryan, this means that when using the lowest latency settings, we will get the same same cpu performance in Live as we do with other host. More flexibility would be good though.

Hi again,

Currently Live is using a ReWire-Buffersize of 256 samples.
As long as always a fixed size is used it's theoretical possible to let the user adjust this value but a fixed size is no must of the ReWire specification and every reWire slave must be able to handle every buffersize and every change of the buffersize.

An of course the differences in performance depends much on the ReWire slave itslef. The performance difference in Propellerheads Reason is less dramatical compared to Project5 regarding the buffersize. This is probably also the reason why this was not a big issue until now because there are much more ReWire masters than ReWire slaves.

regards,
Alex

Alex,

Does this mean that even if I set my audio card to a buffersize of 32 samples, the I will be getting over 6ms latency (at a 44.1kHz samplerate) when using ReWire? In other words, does this mean that the lowest latency when using ReWire is 6ms? If so, that doesn't seem good. When you add the manual adjustment setting, can you allow for lower buffersizes too.

Lastly, tell me if I understand correctly, other ReWire host that use dynamic buffersizes for ReWire will use whatever the audio buffersize is set to. So if the audio buffersize is 4096, then ReWire will use the up to the maximum 4096. Live on the other hand, will use 256 even when the audio buffersize is 4096. But this also means that other host when using 64K buffers will have a ReWire buffer of 64, while Live's ReWire would be at 256ms. So by setting the ReWire buffer to whatever the audio buffer is set to, won't degrade performance and in fact could only prove beneficial. In Live if the audio buffersize is below 64 then the audio buffersize is causing increased cpu usage and not ReWire, but if the audio buffersize is above 256 then ReWire is causing higher cpu usage.

Could you comment on the above Alex?

Thanks

Hi Agnishvatta,

Does this mean that even if I set my audio card to a buffersize of 32 samples, the I will be getting over 6ms latency (at a 44.1kHz samplerate) when using ReWire

Yes, as soon as the Audio device buffersize is smaller than 256 samples, the latencies in the ReWire slave persists at 256 samples (6ms in your example).


Firstly, which ReWire buffersize is set from the different applications that exist on the market is totally in control of their own and I cannot say what exactly they do or not.
- Some have a fixed size (like Live)
- Others depend on the audio interface buffersize but use still an internal maximal ReWire buffersize (mostly 1024 or 2048 samples).
- Others are just use directly the buffersize coming from the audio interface

The main problem is that using ReWire means to handle two (or more) different applications at the same time and each of them has somehow a "preferred" buffersize. Using 128 samples for the one could be good but bad for the another one(s).

But to bring this to an end, the dynamically adjusting of the ReWire-Buffersize is definitively the best what you can do (maybe with an option to switch to a fix size). The options to change the fixed ReWire buffersize will come within the next update. The dynamically adjustment probably not until the next major update.

But to bring this to an end, the dynamically adjusting of the ReWire-Buffersize is definitively the best what you can do (maybe with an option to switch to a fix size). The options to change the fixed ReWire buffersize will come within the next update. The dynamically adjustment probably not until the next major update.

That certainly does bring it to an end. You the man Alex! Openly stating the changes your going to make to ReWire tells me today will be a good day

Dynamic with the option to use fixed will be perfect! I know it will be a while before it comes out, but the fixed options will still help if they come in the next update as you said. But, are you going to allow us to choose any buffersize (as in 32, 64, 128, 256 and so on...)? Well I'll just assume that you'll make it as flexible as possible.

Thanks a lot for all the informative replies; being open and honest about this stuff is a great way to treat Live users.