Yes it´s exactly the same setup, the only other thing is the RME. Thanks for the offer of testing it. Do you also have the Fireface 800? I am not sure if I can give the liveset away, because I play for a bigger electro act and it contains some unreleased material. The other thing is, it´s 3GB large. I could place some dummies in it and you throw your files in, would that be an idea?

Today I worked half of the day, setting up the liveset again but this time in Cubase and with the Fireface and the Behringer, I hope it works. If it works then I know it´s a problem of Ableton and the RME.

Thanks a lot for your offer. Meanwhile I everything in cubase for the show tomorrow but of course I want to find out what´s going wrong there. The Ableton support dropped me a line and said that I should try 256 or 512 as buffer sizes. I will check that when I have some time on sunday or monday and if this doesn´t help, I´ll ask you about testing the dummy set ok?

I was going to ask if there was a reason for having a low buffer size in your set?  I.e on some of the sets I'm programming I automate fx processing on instruments and vocals live and for this a very low buffer is required making the chance of a dropout more likely as far as I'm aware.

I run a set that is about 1.2GB and have done for a lot of big shows with no problems (touch wood) whatsoever in terms of dropouts.  The buffer I set is 512 for this show as we are not doing any fx processing.  We have around 30 songs in the set and jump between them, sometimes automating scene changes sometimes triggering.

Best to provide a download to a demonstration set so that I can try to reproduce.

Ok I was very busy and didn`t have time to check out if the dropout problrem still appears with the changed buffer size. But the same set in Cubase runs very stable - no problems. I played now other gigs with a not so big set in Ableton but it contains much more live processing and I worled with a buffer with 256 and the RME and it worked stable. I hope I will have time to veryfy it with the other liveset but it maybe takes a couple of hours cause the problems don´t appear all the time. But I hope it was the buffer size.

One thing I ask myself: Whan Ableton know that this cann appear with buffer sizes, why do they offer that tool to check out the optimal buffer size? They could simply limit it to 128, 256, 512...

I just got struck down by a real flu, but I received the Set and will take a look as soon as I am back up to speed.

Sorry for taking that long. I just took some opportunities to turn my Macbook Pro (early 2011 i7 2.3) into a complete setup running OS X 10.6, 10.7, 10.8, Windows 7 and Windows 8.

Using the same setup and various versions of Live 8 (including the 64 bit Beta 9) I can play around 45 tracks of "Tarekith' Live Performance Test" (uses only internal Live effects) at 128 samples on Snow Leopard, but only around 20 tracks on Lion/Mountain Lion. The reason seems to be more aggressive power-saving behavior of 10.7/10.8 and Live being especially prone to this.

Both Lion and Mountain Lion were installed cleanly (formatted) with everything being migrated from the Snow Leopard partition afterwards. Doing a clean installation of ML _without_ importing the old applications (and especially without running all my background processes), settings and data from the other partition increases track-count to 24. Still far too low compared to my fully working Snow Leopard installation.

One workaround is to create CPU load, like increasing the CPU Load slider of Coolbook (www.coolbook.se). You can literally watch Live's internal CPU meter drop while Coolbook's CPU Load slider increases.

Now the important part: This all happens the very same with the onboard (PCIe) audio interface of my Macbook Pro. So the RME driver does not seem to be the culprit! If someone experiences less problems with another interface (especially Firewire) then it might be related to those drivers taxing the CPU differently (especially some FW interfaces are known to beat CPU power-saving features on Macs).

The "CPU Load" slider in Coolbook just creates extra load which keeps the CPU from power-saving. In return you get high temps and loudly spinning fans. So it's not a real solution, but something to analyze the problem. The reason why it improves audio performance is because Coolbook runs at a lower CPU priority than Live. Another advantage of Coolbook is that you can control the amount of extra CPU load. Begin with the CPU Load slider at 2 (out of 10) and see how much you really need.

With Core2Duo Macs Coolbook was able to take complete control of the CPU after manually turning off OS X' own CPU kext. I did that in the past (late 2008 MBP) in order to use low CPU loads for low latency work in Live (like sending a single track of vocals through). Unfortunately Coolbook cannot handle i5/i7 CPUs.

The improvements are what I reported in my last post already (same for Lion and Mountain Lion), but I see that I didn't make that clear.

20 tracks without Coolbook's CPU load, 45 tracks with Coolbook's CPU load, aka the same as Snow Leopard without Coolbook. I am measuring against the sinusoid test-tone (0% simulated load, low frequency around 100 Hz) while running playback. The latter allows me to hear even single dropped samples.

Now the question is why 10.7/10.8 doesn't ramp up CPU frequency (and c-states) when Live is already working hard on its limits?!

I am in contact with some new Retina MBP users who may give me some additional information. It's well possible that the CPU power states controls of Lion/ML work better (as in properly) on current Ivy Bridge hardware compared to my Sandy Bridge MBP.

Here is the Live Set:

https://docs.google.com/open?id=0BzLMhL … 0dsNDMxWkU

Start playback of the set (in a loop), turn on Live's sinusoid test-tone (but at 0% simulated CPU load) and then keep duplicating tracks until you hear dropouts.

Dropouts during the "Duplicate" action are normal in Live, but after that it should run without dropouts. And using a low frequency test-tone (around 100 Hz, or below a low-cut filter if your speakers use one) helps to discern dropouts more easily.

Don't turn the volume too loud and keep changing the frequency from time to time to allow your ears to get some rest from the ongoing sinusoid.

Also compare with the onboard sound of the MBP and any other audio interface you might have around. One user of a Lynx Hilo (USB) claims that he can play 48 tracks on his 2.6 Retina MBP without dropouts and _without_ having to create artificial CPU load (via Coolbook). On my 2.3 i7 (2011 MBP) I get 45 tracks on Snow Leopard without artificial CPU load, but on Lion and Mountain Lion I need to keep the CPU artificially loaded to get anywhere near track count.

Good question, it's part of the standard Live library, so I always had it. Or at least I thought so. Maybe I need to check my parameters for saving the set (edited the extra tracks out and saved again under new path). The important part is the CPU load created by the effects, so just load any other sample into it.

This is all messed up. With similar setups we get different results, including results from other people I know (and still evaluate). I will need to run some tests via USB and report back afterwards.

While testing keep an eye on whether you have any external device connected or not. Especially try internal sound without anything external connected (not even an USB stick). Then do the same test with everything connected (especially the FW stuff).

I will post some comparison for internal FW vs. TB-FW soon.

Did you try to download Coolbook and use the "CPU Load" slider (between 2-10) for testing yet? This would give an idea whether you are suffering from the same issues as saw on my setup.

Do you absolutely need a low buffer size?  I haven't had time to do more testing but I was usually only getting dropouts on all the systems I tried when CPU was around 45-50% upwards so that is strange.  Also another thing that springs to mind is what midi ports, if any do you have activated?

Ok, I got answer by the Ableton support and on the phone and by email they just asked the standard about latest driver versions and blabla. They had no idea, no clever questions and of course said they never heard about that, (like always). The funny thing is, we are just on tour and our sound engineer knew that problem since a long time and told me that many people have to open "cpu hungry" plugs to solve that and told me it could be the division by zero thing http://en.wikipedia.org/wiki/Division_by_zero. So the Coolbook cpu thing is the best solution until now as it seems. I set the cpu slider to 4 for the rehearsals and a couple of shows and had no dropouts so far. So thanks for this idea!!!!
Would be cool if we can exchange some news via this post when somebody finds out something. And again: Only Ableton is responsible for that shit in my case, all other programs like Logic and Cubase run well.