I got following results with a live set, I perform fine in OS 9.2.2 with Live 2.0.3 so far - basically 11 24bit audio clips playing at once , plus 4 autofilters, 3 EQ, 1 comp, 1.delay and 1 reverb in economy mode on sends.
When having LIVE 2.1.1 running on a PB G4/800 in OS X 10.2.6 with this live set its performance is still so bad in performance with an RME Hammerfall DSP, that when I start playing first two or more clips I get a short disk overload in beginning(!), BUT gets realy worse when I play all 11 clips together. I get hickups and often a short 3-10 second audio slowdown (like unwanted varispeed) which is so bad at all I wouldn't go to perform with this and can't believe others do with a similar setup.
Now interesting on a special test with LIVE 2.1.1 beeing rewire slave to Logic 6.1 (which has fixed audio buffer sizes !!!) - I can perform the same live set within the rewired Live2.1.1/Logic 6.1 combo, not getting the hickups and all that!!!
this short test leads to proof that audio core support of LIVE 2.1.1 is still far from beeing optimized since first release (only grafics are released better in 2.1.1)
Even the LIVE app is carbonized which puts extra drain on CPU (OK I understand that Abletons didn't go to OS-X native soon as they sell a lot to PC users as well), I can expect that they'll support audio core at its best.
IMO their concept of variable samples possible as buffer for audio-core is not optimal, as you can't simply choose 64,128,256, etc. like in logic, you allways get things like 322 samples as buffer size and their idea to give user most possibilities here is not working out that well in reality.
My tested LIVE/LOGIC rewire combo is not comfortable to realy perform with, as logic is running in continuous play mode and will have a stop mark that has to be set to some certain time (1 hour or so is no problem), it's only a valuable test how a RME card can perform currently and how LIVE 2.x should perform with audio core allready.
Now can we all have any comments from Alex, Christian kleine or the other ableton developers on this ?
Why audio core support is still bad in live 2.1.1 !!!
-
guest
-
rrRand
Add my vote again to the
*we need better OS X AUDIO support from LIVE*...
Yup, graphic performance is now much better but audio really is a cpu HOG... Ableton REALLY needs to get their audio code Altivec-ed. Even the tempo changes when LIVE is bogged down! Nooooo, DON'T change tempo LIVE! I wonder if Ableton will just wait for Panther? Love the design of LIVE but the praying continues...
rRand
*we need better OS X AUDIO support from LIVE*...
Yup, graphic performance is now much better but audio really is a cpu HOG... Ableton REALLY needs to get their audio code Altivec-ed. Even the tempo changes when LIVE is bogged down! Nooooo, DON'T change tempo LIVE! I wonder if Ableton will just wait for Panther? Love the design of LIVE but the praying continues...
rRand
-
Guest
Hi Song Carver,
Can you explain a little about "that bus architecture is BUILT for audio".
I am planning on buying a PC for the first time ever (after using Macs for 10 years) just to run Live, so these issues are very interesting not just to me, but a huge amount of Mac owners frustrated by Live's performance on the Altivec.
Siddhu
Can you explain a little about "that bus architecture is BUILT for audio".
I am planning on buying a PC for the first time ever (after using Macs for 10 years) just to run Live, so these issues are very interesting not just to me, but a huge amount of Mac owners frustrated by Live's performance on the Altivec.
Siddhu
-
guest
-
Alex Reynolds
- Posts: 989
- Joined: Sat Jul 13, 2002 5:48 am
- Location: Philadelphia, PA, USA
- Contact:
The G5s interconnects between processors, memory, PCI bus are designed to move data around much faster than current Intel consumer desktop offerings:siddhu wrote:Can you explain a little about "that bus architecture is BUILT for audio".
I am planning on buying a PC for the first time ever (after using Macs for 10 years) just to run Live, so these issues are very interesting not just to me, but a huge amount of Mac owners frustrated by Live's performance on the Altivec.
-- http://www.apple.com/powermac/architecture.html
What this means in terms of raw performance remains to be seen until units ship.
AU, Multiprocessor and Altivec support would all be nice, definitely, but the G5 looks promising...
Though OT, I'd also like to see more than four Send channels, for the kind of music I make with Live.
-Alex
-
h2
hm, might the above LIVE/Logic 6 rewire procedure a hint where huge performance difference between OS 9 and OS X is comming from as well? - I guess in the described Rewire mode there were only 2 channels used which consumes less CPU obviously, running LIVE in OS-X under core audio is different maybe because currently a Hammerfall DSP card is allwyas in 'all out channel active' mode in X, which can be treated different in OS 9 (user definable outs)?
can the abletons please bring back such funktionality to OS X version or even better is it possible for ableton to offically get in contact with RME on this, cause RME are currently working on a next mac driver update on OS X for their Hamerfall line which could adress such funktionality and a company like Ableton has more influence than customers in a rme-forum.
some comments from mr. kleine on this topic are still cool to have, as this could solve endless speculations.
cheers,
h2
can the abletons please bring back such funktionality to OS X version or even better is it possible for ableton to offically get in contact with RME on this, cause RME are currently working on a next mac driver update on OS X for their Hamerfall line which could adress such funktionality and a company like Ableton has more influence than customers in a rme-forum.
some comments from mr. kleine on this topic are still cool to have, as this could solve endless speculations.
cheers,
h2
Re: Why audio core support is still bad in live 2.1.1 !!!
Why do you think it's bad to use user adjustable output buffers? Application-defined latencies are one of the key features of the CoreAudio HAL.guest wrote:IMO their concept of variable samples possible as buffer for audio-core is not optimal, as you can't simply choose 64,128,256, etc. like in logic, you allways get things like 322 samples as buffer size and their idea to give user most possibilities here is not working out that well in reality.
-
SongCarver
- Posts: 432
- Joined: Mon Dec 17, 2001 3:29 pm
To answer your question Siddhu, (sorry OT)
Nothing has really been tested on the G5's yet, so we really need to wait to see real-world performance.
What is promising though, is the fact that the way in which the bus architecture is designed means that the processor/s can move large chunks of contiguos data (like audio). Or rather, the data does not have to be 'chunked' so much due to
1. the fast and parallel RAM/ disk/ device access due to hyper-transport aided chip
2. The speed of bus (1ghz)
3. 64 bit MAY play a part in audio, eventually
Typically the Macs havs had rather poor buses, but still seemed to perform OK. The CPU's usually would be waiting for data, becuase audio chunks were too big to fit in the cache, resulting in inefficient caching.
As far as I can tell, the spec tests run so far have not really tested the machines in the way that audio/video does (more throughput than calculation)
The 2 altivec units on each chip (twice prior) may prove beneficial too.
BTW (REALLY off-topic Melodyne 2 is coming out..could be great for live performance www.celemony.com )
It's all guessing at this stage, but I can say that bus has Always been the biggest bottleneck for DAWs' IMHO.
WE NOW RETURN TO YOUR REGULAR PROGRAMMING
-SC
Nothing has really been tested on the G5's yet, so we really need to wait to see real-world performance.
What is promising though, is the fact that the way in which the bus architecture is designed means that the processor/s can move large chunks of contiguos data (like audio). Or rather, the data does not have to be 'chunked' so much due to
1. the fast and parallel RAM/ disk/ device access due to hyper-transport aided chip
2. The speed of bus (1ghz)
3. 64 bit MAY play a part in audio, eventually
Typically the Macs havs had rather poor buses, but still seemed to perform OK. The CPU's usually would be waiting for data, becuase audio chunks were too big to fit in the cache, resulting in inefficient caching.
As far as I can tell, the spec tests run so far have not really tested the machines in the way that audio/video does (more throughput than calculation)
The 2 altivec units on each chip (twice prior) may prove beneficial too.
BTW (REALLY off-topic Melodyne 2 is coming out..could be great for live performance www.celemony.com )
It's all guessing at this stage, but I can say that bus has Always been the biggest bottleneck for DAWs' IMHO.
WE NOW RETURN TO YOUR REGULAR PROGRAMMING
-SC
Audio performance under OS X
I've experienced similar drops in performance when going from OS 9 to OS 10. Under OS X I have an echo Indigo (2-channel output) and the RME Multiface (18 outputs). When using the Indigo the performance, for the same number of tracks/plug-ins, is MUCH BETTER than the RME. You would think that there's a problem with the RME system but this is not entirely true. From other accounts, users of similar hardware (Metric Halo has a similar box to the RME Multiface) have the same issue. Just compare Live's performance meter between the sound manager and the RME, the RME configuration chews cpu when nothing is happening. As a consequence, I can't use my RME under OS X, the performance is too limiting. The Echo fares better.
From what i've read (from another audio hardware developer) is that the problem lies in the current state of affairs with Core Audio. Apparently an audio interface tells OS X its configuration (input/output channels). Something like an RME will tell the Core Audio system it has 8 inputs, 18 outputs (8 analog+8 adat+2 spif). Apparently what happens is that Core Audio, in its current state, is continuously maintaining a data flow to ALL the channels on the device, at as of 10.2.6. So even when you're only using two channels of the RME, the OS is shovelling at least 18 channels, possibly 8 more (inputs). In a program like Logic you can limit the number of input/output channels (not explicitly). Eventually Core Audio will support (or implement) the sub-channel control, allowing an app to disable unused (un-selected) audio channels. Applications like Live, Logic, or the driver control panels will need to add new menu controls to allow this explicit control.
The upshot is that this is a disparity between Apple and the audio hadrware/software manufacturers. Ultimately I blame Apple, since OS X's been out for a few years now, and the audio application domain is still shakey in my opinion (i've been waiting for 2 years to not-look-back-at-9, still waiting). We've all gone thru this tirade, haven't we? Just last night I had a flash of switching platforms, after being assaulted by the software migration process.
We've got to get Linux in gear! Hey Ableton! Build a Linux port of Live!
...
From what i've read (from another audio hardware developer) is that the problem lies in the current state of affairs with Core Audio. Apparently an audio interface tells OS X its configuration (input/output channels). Something like an RME will tell the Core Audio system it has 8 inputs, 18 outputs (8 analog+8 adat+2 spif). Apparently what happens is that Core Audio, in its current state, is continuously maintaining a data flow to ALL the channels on the device, at as of 10.2.6. So even when you're only using two channels of the RME, the OS is shovelling at least 18 channels, possibly 8 more (inputs). In a program like Logic you can limit the number of input/output channels (not explicitly). Eventually Core Audio will support (or implement) the sub-channel control, allowing an app to disable unused (un-selected) audio channels. Applications like Live, Logic, or the driver control panels will need to add new menu controls to allow this explicit control.
The upshot is that this is a disparity between Apple and the audio hadrware/software manufacturers. Ultimately I blame Apple, since OS X's been out for a few years now, and the audio application domain is still shakey in my opinion (i've been waiting for 2 years to not-look-back-at-9, still waiting). We've all gone thru this tirade, haven't we? Just last night I had a flash of switching platforms, after being assaulted by the software migration process.
We've got to get Linux in gear! Hey Ableton! Build a Linux port of Live!
...Yeah, linux is a gooood idea. A good platform independant OS like Linux (I think you can run it Mac too?) would be great for music apps, check the "Agnula" distribution website. Linux has GREAT possibilities for running audio. Its just that no software company has taken the plunge yet.
I can't help wondering how much programming must be involved every time an OS gets altered as much as mac OS recently has. It must be a nightmare! I'm sure that Ableton will sort it out once Apple settles on an OS for more than 6 months.
I can't help wondering how much programming must be involved every time an OS gets altered as much as mac OS recently has. It must be a nightmare! I'm sure that Ableton will sort it out once Apple settles on an OS for more than 6 months.
-
Alex Reynolds
- Posts: 989
- Joined: Sat Jul 13, 2002 5:48 am
- Location: Philadelphia, PA, USA
- Contact:
My experience with Live is this
- the audio portion of Live performs pretty much the same on OS 9 and OS X
- the GUI was slower on OS X, but under Panther it seems about the same as OS 9 now
- major audio slowness could well be down to the hardware drivers (in this case, for the RME). I have a Mobile I/O box - it used to be very slow in OS X, but with the new Panther driver for it, performance is about the same as OS 9 now.
So, to summarise - for my system (PB G4 667 + Metric Halo MIO) performance in OS X is now the same as in OS 9. The only difference is that Live doesn't allow one to turn off unused audio channels in OS X.
- the audio portion of Live performs pretty much the same on OS 9 and OS X
- the GUI was slower on OS X, but under Panther it seems about the same as OS 9 now
- major audio slowness could well be down to the hardware drivers (in this case, for the RME). I have a Mobile I/O box - it used to be very slow in OS X, but with the new Panther driver for it, performance is about the same as OS 9 now.
So, to summarise - for my system (PB G4 667 + Metric Halo MIO) performance in OS X is now the same as in OS 9. The only difference is that Live doesn't allow one to turn off unused audio channels in OS X.