Ableton Forum

Hi there, I am working on my new live setup on my macbook pro (See signature) and I am getting constant audio dropouts. I have all the latest drivers for my soundcard etc, so that should not be it. It is as if it is caching something...

I did notice the last time that the CPU went up to 90% for a split second and then down again.

It can go when I go from one sequence with 2 loops to another that has 3 loops. CPU Usage is at 23% most of the time.

I am playing live tomorrow, so urgent help is needed

Thank you very much in advance!

Regards,

Nemo DX Zimmer

a lot of us are having the same problem and with mac's no less. I don't know the answer yet but keep looking and keep posting if you find anything.

Or at least if it was happening before this it wasn't bad enough to notice.

I'm running on a MacBook Pro Core 2 Duo 2.33 GHz, 2GB RAM with an Echo AudioFire4 and a 500GB WD Firewire800 drive. As I'm going through a project the drop outs happen when new samples are reached in the arrangement view. I can see a brief blip on the Disk indicator in Live. If I hop around to the different sections, sort of in an effort to get Live to pre-load or cache them, and then go through it's fine. If I don't do this Live will drop for a split second on each new recording but only 1 time for each one.

So if I play it through it'll skip. If I play it through again, it won't.

My guess is the audio lookahead or caching algorithms have a glitch somewhere. I may roll back to 6.05 to confirm that this didn't happen then.

Is everyone who is having this problem on 6.07?

-M

Hi MobiusB, I have already checked with 6.05, and it is exactly the same. I thought first that it is a problem with my external harddrive, but it does the same on the internal one.

And indeed, this has to be some kind of weird caching problem...

MobiusB wrote:
My guess is the audio lookahead or caching algorithms have a glitch somewhere. I may roll back to 6.05 to confirm that this didn't happen then.

-M

This is totally whats happening.. Live is not Pre-buffering or caching or whatever you want to call it as the song is playing.. The song starts from the top and there is no disk activity and then it gets to a certain section of the song and decides "Oh shit, i should load all of these files right now.." and then it freezes with the hard drive light solid orange..

I can run the same files in live 5.2.2 and not experience the problem.. I can also run the same exact files in reaper and watch the hard disk read amount through the snazzy performance meter that program has.. It says I'm pulling 5.09mb/sec while playing back 22 88k wav files. No glitches, no hangups, no problems. So, its definitely something with Live 6. I tried all version from 6.0.1 to 6.0.7 and it happens on every single one of them.

Wow, happens on everything from 6.01 to 6.07? I gigged with my setup last month using 6.05 and definitely did not have this problem. I can't recall when it started recently but it's definitely there now.

And people seem to be using different sound interfaces and I initially wondered if it was something with my AudioFire. But maybe not. We know we have OS X in common and I think everyone so far has said MacBook Pro. Just on the chance it isn't Live itself, what plug-ins are you all using in the projects that have the problem? I'm using Absynth 4.01 and Battery 3.01, both as AudioUnits and also using Impulse.

I just sent a link of this thread to support and asked if they are aware of anything. We'll see what turns up.

-M

Well, I'm on a windows Box.. I posted a thread a few down from this one yesterday.. http://www.ableton.com/forum/viewtopic.php?t=64886

Happens on all of them.. yes.. And i did a Hard drive speed check on my drives and they are bursting at 245mb/sec and a average of 70mb a sec.. Don't even know why I'm checking that stuff, it works fine on everything else.

I guess this is the first time Ive noticed because this is the first time I'm working on a project that is recorded in 88k.. I usually run 48k and haven't ever noticed this problem in 6 or 5 for that matter..

Ah, ok so both platforms are seeing it.

My project is at 44Khz. So pretty standard there. And this particular project is much lighter with tracks and plugins than a lot of my other stuff and I never saw it with them. I'll try loading some of those up and see if it's better or worse.

It definitely didn't always do this with 6 for me. But I definitely gots it now.

-M

I've been getting this on a macbook, then the other day i got it on a desktop PC on one project - only seemed to notice on that one project so far

but something is afoot

Somethings strange is going, thats for sure... And look at how many threads are on the front page that all seem to have the same problem. Most of those threads are high end systems too. And it seems like its happening out of nowhere.

Doesn't appear to be anything OS specific or Processor specific either based on who's having these issues and what they are using..

I'm still leaning toward the pre cache suspect. That would make sense when it trys to load 22, 88k/24bit files that are 80 megs a piece, all at once during playback.. Thats no bueno..

Testing with reaper, it starts pulling from the hard drive the second you hit play... and the disk activity is pretty solid throughout the song.. However, it plays without problems.. unlike live 6.

I have the same problem and probably since the V6, especially after opening a song, each new clip starts with a noise.

Mac G5 DualCore 2x2GHz OSX.4.7

Hi there,

Same problems here: http://www.ableton.com/forum/viewtopic. ... 0&start=15

It's pissin' me off, all these good toys in V6, but unusable for me

Hi,

I've just moved to Live 6.07 for gigging (from Live 4) and been having the same problem with large Live Sets.

My gigging set contains 1.7Gb of clips and is 128 tracks wide x 339 scenes deep. This represents 11 "songs" as multitracks combined into one large set.

The set will play happily until about the 5th song then start glitching, staggering, dropping out etc. We have had to resort to splitting the showload into two halves of 5 and 6 "songs" respectively, and using a 60 second ambience played off an iPod to cover loading the second half.

We just got back from our first ever gigs/tour with Live 6. We played 10 "songs" (5 in each load) each night until the last gig of the tour when we played all 11. And wouldn't you know it, on the 11th song Live started to stagger and drop out. Fortunately not badly enough to stop the show, but definately noticable to everyone in the club. (I had to make a little joke over the mic about our computer being tired and needing a sleep).

My question to the Abes is: what fundamental part of Live's design is being exceeded here? Some form of cache limit somewhere? Can you let us know without breaching any NDA about Live's internal architecture? I am just a musician and not a coder so I don't know about these things.

In closing, check the contrast between the specs of our old gigging system (which was loaded with as many tracks and clips as possible before dropouts would occour) with the new one:

Old Rig:
Powerbook G4 single 500MHz
1Gb RAM
OS 9.2.2
Live 4.02
RME Multiface/PCMCIA
110 tracks x 250 scenes
1.3Gb of clips

New Rig:
MacBook Pro C2D 2.33GHz
2Gb RAM
OS 10.4.9
Live 6.07
RME Fireface400/Firewire
128 tracks x 339 scenes
1.7Gb of clips
(has to be split into two halves)

So the new rig can only handle roughly HALF the showload of the old rig without glitching! I accept that not all conditions are equal in the two cases, but I would have hoped to at least stay the same, and not move backward in capacity.

Please, is any Ableton at liberty to shed any light on this?

Best,
Paddy

hi

ableton 6.05/6.07: same problem here. my giggin-set contains 0.5 gb of clips and 90 tracks with more than 100 scenes in session-view.

djing through scenes, top-down. in some scenes ableton has to start more than 6 clips. --> release short-dropouts and a short cpu-overload with 200-300%.

high-end-system too. and it seems like it's happenning out of nowhere.

unusable during a club-gig!

@ ABLETON: drop some statements & please analyze that. there's something going wrong with audio lookahead or caching algorithms. no matter external or internal hd. same problem with external hd (usb, 7200 u/min.)

@ pitch-black:

do you use more than 1 midi-controller with one laptop? i work with 2 midi-controllers with much midi-assignments and have noticed, that some interactions with the midi-controller can also release drop-outs and cpu-overloads.

so my view is: audio lookahead, caching algorithms in combination with midi-controllers.