Puzzling issue - anyone know what's up?!

[TomViolenz]

Finally did the firmware update for the SSD.
Problem pesists.

Now what?

[dixie237]

Make your 32bit samples 24bit and try again

This?

[M-bition]

and I also learned to use 24bit only. I had issues using/playing two ore more different samplerates (in rare occasions)

Stick to one samplerate for performing live

[TomViolenz]

nah, the 32bit thing is beside the issue. An SSD should be more than able to handle that.
(Just doing the math here: in total 30 samples, clips and one shots playing at the same time. A 16 bar loop (ca. 30seconds) at 32bit is ca. 10MB big. So 0.33MB/s times 30 samples = 10MB/s. SATA II is at 300MB/s! And SSDs can easily saturate SATA II)

Besides I have loaded all the clips into RAM atm and the problem still persists.


I also have a condition how I can trigger the crash reliably, while it has been running smoothly before that no matter how many clips I ran.


The only consistant thing seems to be that I need to use follow actions for these crashes to happen. I wonder if it may be a bug after all.
So atm I don't use follow actions for that reason, which is not sooo bad, but I just feel a bit uneasy that it might crash when it's least welcome

[fishmonkey]

Finally did the firmware update for the SSD.
Problem pesists.

Now what?

are you still getting the disk overloads?

[M-bition]

nah, the 32bit thing is beside the issue. An SSD should be more than able to handle that.
(Just doing the math here: in total 30 samples, clips and one shots playing at the same time. A 16 bar loop (ca. 30seconds) at 32bit is ca. 10MB big. So 0.33MB/s times 30 samples = 10MB/s. SATA II is at 300MB/s! And SSDs can easily saturate SATA II)

Besides I have loaded all the clips into RAM atm and the problem still persists.


I also have a condition how I can trigger the crash reliably, while it has been running smoothly before that no matter how many clips I ran.


The only consistant thing seems to be that I need to use follow actions for these crashes to happen. I wonder if it may be a bug after all.
So atm I don't use follow actions for that reason, which is not sooo bad, but I just feel a bit uneasy that it might crash when it's least welcome

I know it doesnt make sense and You may be right but if you do not try it you will never know..... and I do not think it works that way. The complete sample has to be loaded and read every time imo so that is hundreds of MB's per second.
Because you loaded them all into RAM > you are using up a lot of your RAM > and to find new resources it might be that Live or your OS still reads them from disk.


I remember having disk overload issues putting all samples in RAM while having no problem turning RAM of.
I also suspect all the samples in Drumracks and or sampleracks are loaded automatically into ram which which takes up ram space also (perhaps for quick acces)


edit;
Another thinking of me; having multiple clips of the same sample but with different automation in it will cause different multiple samples after all. 1 sample in 3 clips = 3 samples
Another thinking of me; having clips with automation will still cause your samples to be read. Sample can be loaded in RAM but not the automation
Another thinking of me; Follow actions with clips with different automation may give hiccups because a lot is happening and changing at the same time while 1st clip stops and next clip starts to play. Live may not like having automation and having follow actions at the same time in certain cases

[[jur]]

At this point, why not contacting the support@ableton.com ?

[TomViolenz]

nah, the 32bit thing is beside the issue. An SSD should be more than able to handle that.
(Just doing the math here: in total 30 samples, clips and one shots playing at the same time. A 16 bar loop (ca. 30seconds) at 32bit is ca. 10MB big. So 0.33MB/s times 30 samples = 10MB/s. SATA II is at 300MB/s! And SSDs can easily saturate SATA II)

Besides I have loaded all the clips into RAM atm and the problem still persists.


I also have a condition how I can trigger the crash reliably, while it has been running smoothly before that no matter how many clips I ran.


The only consistant thing seems to be that I need to use follow actions for these crashes to happen. I wonder if it may be a bug after all.
So atm I don't use follow actions for that reason, which is not sooo bad, but I just feel a bit uneasy that it might crash when it's least welcome

I know it doesnt make sense and You may be right but if you do not try it you will never know..... and I do not think it works that way. The complete sample has to be loaded and read every time imo so that is hundreds of MB's per second.

But it works pretty much exactly like this. Yes, there is an audio buffer, but it is certainly not filled with the whole sample (a few seconds of it at most).
And I have good resons to not compromise on the quality at this point in the process. I did not mention this, since I didn't find it relevant to the discussion, but my performance set also doubles as my arrangement/ composing set. This has many advantages since every arrangement I record is at the same time a training for my performance and every performance can potentially become part of the arrangement of a track.
But for the following mixing and mastering steps I want to have as much headroom as possible remaining.

Because you loaded them all into RAM > you are using up a lot of your RAM > and to find new resources it might be that Live or your OS still reads them from disk.

I have 16 GB of RAM. The RAM monitor so far showns me that a good chunk of it is still free. So there is no paging happening.

I remember having disk overload issues putting all samples in RAM while having no problem turning RAM of.
I also suspect all the samples in Drumracks and or sampleracks are loaded automatically into ram which which takes up ram space also (perhaps for quick acces)

No, not automatically. But if you use Sampler you can use its RAM toggle to load all the contained samples into RAM. Which is what I did.

edit;
Another thinking of me; having multiple clips of the same sample but with different automation in it will cause different multiple samples after all. 1 sample in 3 clips = 3 samples
Another thinking of me; having clips with automation will still cause your samples to be read. Sample can be loaded in RAM but not the automation
Another thinking of me; Follow actions with clips with different automation may give hiccups because a lot is happening and changing at the same time while 1st clip stops and next clip starts to play. Live may not like having automation and having follow actions at the same time in certain cases

None of the clips have automation (basically all the automation is either already written into the audio when I recorded it, or added in this live performance step via the 7 different controllers I have connected.

[TomViolenz]

Finally did the firmware update for the SSD.
Problem pesists.

Now what?

are you still getting the disk overloads?

I have seen it on occasion but rarely, and the last few times I managed to make Live crash via that one combination of actions that now reliably crash it, I haven't seen the D sign light up once.

BUT, and this is only preliminary so far, I did a collect and save onto the new USB 2 stick I had to buy and ran the set from the stick (the clips were still loaded into RAM) and for the few times I ran it and performed the reliable crash action mentioned above, Live didn't crash.
(This is in so far still preliminary that it doesn't always crash in the other case either, so I want to keep doing it a few more times before I'm reasonably sure)

In this case it would point to my SSD being faulty, but DiskUtility not picking up on it. Do you know of any other apps I could use to test the integrity of my SSD?

[TomViolenz]

Ok, the set running from the USB stick has the same problems, but it still may shed some light on the problem.

If I let it run in a way where it doesn't crash, but keeps running via follow actions the huge CPU spikes start happening after a while (ca. 20min) too just like when it's run from the internal SSD.

But what is interesting is that the USB stick has a LED light that blinks when data is accessed and while in the beginning when the CPU doesn't spike the LED remains dark (because the samples are in RAM), it starts blinking like crazy when the CPU spikes start happening. (The D symbol in Live is not turning on though)

And when I stop playback and all clips in Live the CPU spikes continue and the "Buffering Sample" progress bar on the bottom of of the screen turns on and hangs at 98% of ever and ever while the LED light keeps blinking like crazy.

So I don't think anymore that it's my SSD.

[stringtapper]

But for the following mixing and mastering steps I want to have as much headroom as possible remaining.

Are you working with weaponized sound??

24-bit is plenty.

[TomViolenz]

yes

[H20nly]

I wouldn't put too much thought into the activity light on the USB drive. It simply indicates disk access (reads/writes)

I could be wrong, but I believe the disk indicator in Live will be pointed at the drive Live is installed on, not where the track/samples are stored... since theoretically, you could have samples stored across multiple volumes.

[Piplodocus]

I've had similar-ish bugs with both SSDs and genuine Ableton bugs which they fixed for me. What version Live? 9? Have you actually asked tech support? They're generally pretty helpful.

[franknputer]

When you take a look at Console while Ableton Live is slow, do you see the whole log filled with messages likes this one?

20.09.15 17:20:07,429 Live[661]: assertion failed: 14F27: libxpc.dylib + 33325 [5C829202-962E-3744-8B50-00D38CC88E84]: 0x13
20.09.15 17:20:07,435 Live[661]: assertion failed: 14F27: libxpc.dylib + 33325 [5C829202-962E-3744-8B50-00D38CC88E84]: 0x13
20.09.15 17:20:07,441 Live[661]: assertion failed: 14F27: libxpc.dylib + 33325 [5C829202-962E-3744-8B50-00D38CC88E84]: 0x13

Maybe a few hundred of them per second? This is what happens on my computer when it gets slow and Live becomes unusable. Would be intersting to see if it is the same problem that you are experiencing.

Dunno if this is OT for the thread, but I just had this start happening to me too - same error, and Live is useless. REAL minimal set, too - I was just getting started last night, but today it refuses to work...