(53866345) L9.05 - CPU & audio buffer glitch on move note

[Angstrom]

installed L9.05 hoping it would resolve some of my issues with L9, unfortunately not.

this issue has been present since around L9 b50 , glitches on moving a note.
I previously reported it mysteriously fixed, but I was mistaken. The issue arises when moving a note, whether the set is running or not.

Issue: moving a note with the mouse causes CPU spikes, audible pops and bursts of static.

Reproduce: (on my system) simply moving a note with the mouse.

Outcome: bursts of noise, static bursts, pops, and CPU jumps from the resting state of 10-11% to around 50%. While there are no audio indications on the L9 meters shows the audio bursts come from the soundcard driver. Moving a note when the song is running produces even worse outcomes.

Expected outcome: no noise, no CPU jump. I expect to move a note without CPU spikes and audio bursts, as L8 which works perfectly.

Tried: upping the buffer size, but no difference is made. L8 works perfectly with buffer of 128 samples, L9 does not work perfectly with any buffer size.

Observed the issue gets progressively worse the longer the song is open. When the song is first opened moving this same note will take the CPU from 11% to 26% . After the song has been open 30 minutes the action causes the CPU to jump from 11% to 46% (or higher)as seen in the GIF

Image : moving a note with the mouse, even when the song is stopped, causes visible CPU jumps and (non-visible) audio bursts at the same time





test system:
L9.05 final 32 bit,
Win 7 64 bit
RME Fireface 400

[taoyoyo]

I can repro here on OSX, 10.8.4, 9.0.5 64bit.

Huge rise in CPU usage even with the project not playing!

Same thing (though not as dramatic) happens here with dragging a clip around Session view.

[Angstrom]

I've been in contact with support about this, and sent a pack along. Hopefully some cause can be found.

[Lumix]

I've been in contact with support about this, and sent a pack along. Hopefully some cause can be found.

thats a strange bug hope this will get fixed - it would drive my insane.

[Evengy]

i reported that a few weeks ago and they confirmed that. hopefully it will be fixed in the next betas
drag more samples into drum rack chains and make it more worse ;/ every action like adjusting, velocity, note lenght etc. it´s the same error pattern.

another thing is that i use 14 drum rack cells with 270mb one shot samples and it needs 2,7gb ram. ableton told me that they will check it too.

[[mal]]

Hi Angstrom,

I have tracked this but could not reproduce heavy load on moving/snapping one note, neither the artefacts in audio. However I did see a moderate increase with rubberband selections over several notes being moved. This was at 32 samples latency using a RME babyface
Do you by any chance use process explorer for windows, this would allow us and you to see if it is the GPU or the CPU being hit so hard and would be helpful information for us.
I would also be interested in how the latency monitor would look like on your system when moving notes:
http://www.thesycon.de/eng/latency_check.shtml
The process explorer / latency monitor would show which services are taking up the resources and would show if this was a case of mouseware such as Logitech / microsoft colliding with high prio UI or audio threads.

Last question, do you have anything in your options.txt?, if yes please let me know.

Best,
Mads

[Angstrom]

Hi Mads,
Apologies, as I also sent this issue directly to support@ it's been assigned a different case number by Marco

ableton985080

He has a status pack dump, and some more detail on what it takes to trigger this.( about 20 minutes of note editing with the mouse)

At the moment I'm on an iPad, but I do have process explorer and I can provide that information and some Option.txt variations when I'm back at my desktop. From memory all that is in there is the Absolute mouse mode entry (Wacom tablet mode). However I have noticed this issue while I had no options.txt in place ( I deleted it to try resolving issues during some later betas). For me this issue has occured since around b50, but not prior to that. I will dig out the original getSatisfaction report link if you need it, and get a specific beta number where it first started/was reported.

---

Edit : the ableton beta getSatisfaction community is closed, so I can't link you to my previous bug reports on this issue.

[siliconarc]

steve, does the set itself have the same cpu load as the 'spike' load when playing?

just tried this here and see the same spike with a very simple set.
all i have in the project is one audio track with a 2-chain audio effect rack, w/ a cpu-heavy spectral plugin on each chain.
this one track runs at around 60% cpu (expected - plug is v.heavy!).

after adding a drumrack track with a new clip & note, i see the cpu jumps up as if the track was playing.
but here, it turns out i don't actually have to drag a note to see the spike.
in fact i don't need to create a midi track at all! just clicking anywhere in one of Live's editable areas of the gui will trigger the spike. i'd just never noticed before.
maybe this only occurs with high cpu load sets, is why i ask...

10.8.4, 9.0.5.

[Angstrom]

steve, does the set itself have the same cpu load as the 'spike' load when playing?

No not really, the set in the image peaks at about 42% in best case scenario (open Live 9 play the set without editing anything). In the pack I sent to Marco: I stopped the set and moved a note, and hit around 57% CPU or higher, just from moving a note in a stopped track. The resting state of the stopped track is 11%.

While this particular set is quite big I have noticed this bug before in really small sets.

I will now do some DPC latency tests, and use processexplorer

[siliconarc]

righto, maybe a diff issue then ?

mads, does Live 9 (32-bit here) perform some type of 'soft-deactivate' of vst plugins that aren't currently audible? like a gate for the cpu? or are the plugins themselves capable of this now? (i thought this was a VST3- or AU-only feature..)

reason i ask is that, in Live 8 the cpu runs at full tilt regardless of the plugin's audible state (transport not playing), while the same set/situation in Live 9 will drop to around 0% after a second of silence, but clicking anywhere will 'open the gate' and up jumps the cpu to full for a second.

[Angstrom]

Hi Mads

What was in my Options text was

Code: Select all

-AbsoluteMouseMode
-EditorNoteResizeSnapsOnGridOnly

that last entry was some wishful thinking by another forum user hoping to deactivate the "smart" snap feature. I just deleted that entry and now my options text is

Code: Select all

-AbsoluteMouseMode

this produces exactly the same results, high jumping CPU when moving a note around.
Here is an image of what process explorer / Latency checker tells me for this user

For this image I moved the note about directly after loading the set, so I only reach 47% , if I kept this set open for longer I could reach a higher peak.

[Raffi2508]

Exact same problems for me. Beside abnormal CPU usage in general. This is what I wrote in the CPU issues thread:

Same issue here on a Macbook Pro i7 2.4 late 2011 16gb RAM running ML 10.8.3. Fans are spinning like crazy on projects reaching more than 40% CPU. This is since Live 9.0.

Do you guys also have crackles when selecting notes in the midi editor (with speaker icon ON)?

Switched back to Logic for now as the fan noise make it unworkable.

edit: Actually when selecting notes in a busy project (30/40% CPU) the CPU meter spikes and fans will go up causing the crackle, weird thing is, this even happens with the speaker icon off (no sound)! Could this be related to a graphic/videocard bug? Happens also when using the internal MBP videcoard (no external screen)...

[Angstrom]

Just keeping other users up to date on this

Marco (Ableton) suggested the issue might be my approaching the 32 bit memory limit. In this particular set that theory seemed plausible as it uses a lot of resources. So, I installed L9.05 x64 and the most recent Max 64 bit version and retested.
My machine has 16gb of memory installed, and this set requires around 2gb meaning that by using L9 x64 there should be no memory limitations with this set. I retested with this set-up.

Sadly the same results are visible in the 64 bit version, so it seems likely that a memory limit is not an issue.

In addition to that test, I have seen this issue arise in other (low resource usage) sets, which would seem a second nail in the coffin of the theory.

A shame to eliminate a promising theory, but hopefully the elimination leads to further theories.

[Angstrom]

a further update : this is in L9.05 x64, with 16gb of ram, and with no Ableton Options active.

Audio preview of midi notes(little headphone) is not active. Adding notes is not making noises, this is purely the CPU load of adding a note.

adding a single note to a stopped set, through clicking, takes the CPU from 1% to suddenly peak over 20%.

[Angstrom]

Latest update : Ableton have been able to replicate the behaviour/outcome. Which is a good beginning. It's impossible to start a bug hunt if you don't have one of those.