Ableton Forum

I have changed this post to reflect my newest finding! For details see my post later on.

There are a couple of bugs with Latency Compensation and Plugin (VST) Buffers concerning both Live 6.10 and 7.01 on my Windows XP AMD A64 X2 (Nforce4) computer. I will mark where a bug is only affecting one of the two versions or has a differenct effect. These bugs seriously affect timing of Midi Instrument Plugins, both internal and external (VST) ones. If needed by Ableton staff I can provide audio files demonstrating all problems I am posting about down below. I did my tests with Simpler, Battery, FM8 and Crystal.

First of all

In Live 6.10 when you warp a clip at original tempo in "Beats" mode the clip can shift by 1 to 1.5 samples after a few ms when (re)starting an already playing scene. Using "High Quality" mode even at original sample-rate and any mode will always shift the clip by one sample. This does not happen in Live 7.01.


1. Attack timings fluctuate/are unstable for External (VST) Plugins

In both Live 6.10 and 7.01 timing of Attacks for external (VST) plugins are not stable neither with nor without Latency Compensation turned on (it really makes no difference whatsoever). The higher the Plugin Buffers setting the more attack timings of external plugins will be at odd. It can be made audible with a simple cancelation test for values downto 32 samples and can even be made audible for values up from 256 samples without a cancelation test by simply playing 1/16 notes in succession. To make sure it's not a Battery issue I also tested this with FM8 and with the non NI "Crystal" soft-synth.

This does not happen with internal plugins (Simpler) and I am very unhappy about this finding, because there is not even a workaround! You can only try to minimize it by using as few Plugin Buffers as possible (32 samples for 7.01, fixed value for 6.10 only as described below)


2.1 Plugin (VST) Buffer in Live 6.10 cannot be changed

Short story: Changing Plugin Buffers via Preferences in Live 6.10 has no whatsoever effect. The buffer size seems to be fixed, most likely to some small value like 64 samples and not to "As Audio Buffers" or any high value. Latency Compensation is "correct" with this fixed buffer size in Live 6.10, 7.01 corrects this issue while introducing two timing bugs linked to this setting (see 2.2).

Internal Midi Instrument Plugins (Simpler) do not seem to be affected by this setting at all.

2.2 Plugin (VST) Buffer in Live 7.01 is always Latency compensated as 64 samples

This means that in contrast to 6.10 you can change the Plugin Buffers and it does audibly have an effect (including a bug, see below), but Latency Compensation will always tread it as 64 samples. So any value apart from 64 samples (including "As Audio Buffers" if Audio Buffers are not =64 samples) will lead to timing differences. Latency Compensation is "correct" for a setting of 64 samples and can be made "correct" by setting Track Delay according to the difference between 64 samples the set Plugin Buffers (i.e. 512 Plugin Buffers need -448 samples Track Delay on VST tracks, else you will experience a latency of about 10 ms!).

Additionally the "As Audio Buffers" setting does not recognize changes of the sample-rate of your audio-card via Preferences unless you change it to some other value once and then set it back to "As Audio Buffers"

Internal Midi Instrument Plugins (Simpler) do not seem to be affected by this setting at all.


3. Simpler plays the first note of a midi clip 1.0 ms/44 samples too late if a note was played at the end of the preceding/loop

This affects both Live 6.10 and 7.01 the same and is a minor issue compared to the other ones. Regardless of wether Simpler is used in a Drum Rack or on its own it will play the first note of a clip by 1.00 ms/44 samples too late if the preceding clip played a note at the end of the clip. This happens both with loops and with follow action clips.


I have changed this post to reflect my newest finding! For details see my post later on.

Maybe someone could test these things on another computer before I forward it to Ableton support via mail?!

Timur wrote:The best achiveable latency compensation will bring them as close as a difference of less than one sample (<0.01 to 0.02 ms). This should be good enough for all practical uses and I don't mean to be nitpicking, it just needs to be clear before reading on about the serious issues.

It can be proven by doing a cancellation test via Invert Utility of an Audio track playing a percussive clip concurrent with a Midi track playing the very same click via Simpler or Battery. There will always remain a cleary audible "click" sound at the beginning of the attack phase and remaining noise during the sustain/release phase because of the time divergence.

I'm having some PDC-related issues myself, which I'll post in a thread later on, but I just wanted to bring up 2 things here:

1) The smallest possible unit of time in digital audio is a sample, so how is it possible for tracks to be 'out' by less than a sample?

2) The residual transients in your inverting test have another explanation other than timing differences... if you look closely, Battery and Simpler both share 0.1ms as the lowest possible attack time... not 0ms, but 0.1 ms...

That is more than enough of an attack to 'let through' some of the transient from the audio track, which would remain uncancelled by the phase reverse...

I have tested Battery 3 and Simpler in the same scenario you have envisaged before, and when volume envelopes are enabled in both plugins, there is definitely a click... but when you disable volume envelopes altogether in Battery 3, they null to total silence... Unfortunately you cannot turn of the volume envelope altogether in either Simpler or Sampler (which hopefully they will include as a feature soon) so you cannot do the same test with those plugins...

I should also add... point #2.2 in your post above has solved a problem I've been having since version 5 - at some point in big projects, automation seemed not to be latency compensated properly anymore... for example, a filter cutoff curve that looked like this:



Would end up sounding like this:

pdc_thing.mp3 - 0.19MB

You can clearly hear the filter cutoff coming back down at the end of the clip, when it should keep ascending right until the end...

Changing plugin buffers to 64 samples has fixed this problem

Vance wrote:1) The smallest possible unit of time in digital audio is a sample, so how is it possible for tracks to be 'out' by less than a sample?

I have been asking this myself. Live 7 allows to set Track Delay downto 1 sample precision but I was not able to cancel any of these combinations of tracks: Audio clip vs Battery, Audio Clip vs Simpler, Battery vs Simpler.

1. Latency Compensation could still be 'out' by less than one sample. Live and the Plugins would still be calculating on a sample basis, but since they are indipendend threads (both internal and external plugins), possibly even running on different CPU cores, it is well possible that they are not entirely in sync. So when Live has to sum up the signals it will most likely just use the sample-rate basis of the host process/thread aka Master bus and cut off anything that is out of sync. Imagine it like this:



I will do another test with multi-processor support disabled, maybe it makes a difference. But this does not have to be bound to multi-processor support and I don't really know if it works like this internally. It's well possible with any realtime calculations that are done on serial systems like CPUs. At one point you have to bring the different streams together and since CPUs do not calculate on a sample basis I can imagine some problems when gettings streams of audio-data from different sources synchronized.

Anyway, today I managed to synchronize the Hold/Sustain/Release phase of an Audio clip vs Battery, only the attack phase stays out of sync because of the fluctations happening with VST plugins. It seems that these fluctations only happen in the attack phase. I found a bug that in Battery that the Hold parameter will be ignored if you use AHDSR instead of AHD. But that didn't matter for my tests because I always chose a note length as long as the loop.

I also found the reason for the -1.0 ms/-44 samples offset of Simpler. It only happens when a Midi clip play a note at the end of a loop. If there is no note playing at the end of a loop there is no offset between a Simpler and an Audio track. If there is a note at the end of a loop then the first note of the next loop start will be off by -1.0 ms/-44 samples!

2. Volume/Gain difference

I made sure that all three tracks reach the same peak upto the second digit after the point. Maybe I did not try hard enough last time which would be an explanation why the Hold/Sustain/Release phase did not cancel before. I may have been fooled by the AHDSR bug in Battery and confused some tests since it was quite late that day.

Simpler always seems to change my samples (see below), because of that a setting of 0 dB will be peak 0.01 dB lower than the same sample being played back on an Audio track. But even if you push gain by 0.01 dB to match peaks the samples will still be different from beginning to the end.

3. Different playback envelopes (AHDSR)

Battery allows to switch AHDSR off all together and pure sample clips in Live with FADE deactivated should not be enveloped at all. So playing back a clip without envelopes in Battery against an Audio track should cancel. And in fact today I managed to do it with Audio Clips vs Battery, but not with Audio Clip vs Simpler and not with Simpler vs Battery.

Simpler always seems to change my samples! I did not manage to find any ADSR setting in Simpler that cancels with the other tracks. Not only the attack phase is affected, but also the Hold phase. Setting Battery's envelope to exactly match Simpler's does not help.

2) The residual transients in your inverting test have another explanation other than timing differences... if you look closely, Battery and Simpler both share 0.1ms as the lowest possible attack time... not 0ms, but 0.1 ms...

Battery allows a value downto 0.0 ms, only Simpler is restricted to a minimum of 0.1 ms. While Simpler changes the sample anyway I also did not manage to get rid of a very short click with Battery.

That is more than enough of an attack to 'let through' some of the transient from the audio track, which would remain uncancelled by the phase reverse...

This is not big problem anymore that I managed to sync the Hold phase, but what still worries me is that the Attack of Battery and other VSTs varies. The ammount of variance is linked to the number of Plugin Buffers being set, the bigger the buffer the worse the variance. And this is not so much a problem of Latency Compensation, but can audibly modulate the sound when you play fast successions of notes with any VST plugin.

I have tested Battery 3 and Simpler in the same scenario you have envisaged before, and when volume envelopes are enabled in both plugins, there is definitely a click... but when you disable volume envelopes altogether in Battery 3, they null to total silence...

I cannot acknowledge this. I tried both turning envelopes off in Battery and setting them to the same attack settings as Simpler, both did not cancel. But since I cannot get Simpler to cancel to an Audio track even I may still do something wrong.

I will edit my first post in this thread to reflect my new findings.

Timur I am puzzled by this. How are testing the PDC accuracy?

I cannot repeat the problem you are getting. I have a set of 16th notes in a clip and they are triggering Pro-53. Each note is exactly on time and renders perfectly on time too. Its certainly triggering in time to 0.1mS.

My buffer setting is 128 so I should be experiencing some sort of delay if what you say is right. Or am I not testing this right? Should the CPU be under strain at all?

Win XP SP2 Live 7.01. Delta-44 soundcard. P4E 3.0GHz, Intel D865Pe, 2GB RAM.

Vance wrote:You can clearly hear the filter cutoff coming back down at the end of the clip, when it should keep ascending right until the end...

Changing plugin buffers to 64 samples has fixed this problem

I did not test automation envelopes, but in 6.10 changing Plugin Buffers did not change anything for my test at all, it is set to a fixed rate and always compensated correctly.

But in 7.01 my current value that compensates correctly is 32 samples now instead of 64 samples. There must be a reason why it has changed. I will report back once I have found it.

Synthbuilder wrote:Timur I am puzzled by this. How are testing the PDC accuracy?

I cannot repeat the problem you are getting. I have a set of 16th notes in a clip and they are triggering Pro-53. Each note is exactly on time and renders perfectly on time too. Its certainly triggering in time to 0.1mS.

My buffer setting is 128 so I should be experiencing some sort of delay if what you say is right. Or am I not testing this right? Should the CPU be under strain at all?

At 128 samples you wont notice much of a delay. Actually there are two problems with Plugin Buffers like explained above:

1. Only one setting will be latency compensated correctly by Live. With large Plugin Buffers you can notice a delay.

2. Attack timing of external plugins varies with Plugin Buffer size. This can lead to audible sound modulation when playing notes in fast succession. For most practical uses it will likely not be a problem, but there is something wrong with the internals of Live at this point.

I have found the reason why the "correct" value changes. Latency Compensation will always get corrected by Live upon restart or starting a new project. That means that if you make any changes to Plugin Buffers or change Audio Buffers while using the default Plugin Buffers "As Audio Buffers" you either need to restart Live or start a new project for Latency Compensation to recognize the changes.

It is still a good idea to chose Plugin Buffers as low as possible because these seem to be added to your Audio Buffers. So setting them to "As Audio Buffers" will double the effective latency time for external plugins.

Timur wrote:you either need to restart Live or start a new project for Latency Compensation to recognize the changes.

hi timur

try clicking the cpu thing to disengage and re engage your audio device, i wonder if that may help.

Using the CPU button does not work, nor does switching off the audio-card work. I have found done some more test with Simpler and also Sampler. Seems as if normal audio clips on Audio tracks use the very same attack minimum of 0.10 ms, cause I managed to cancel Sampler vs Audio Tracks and Sampler's minimum is 0.10 ms.

> Live and the Plugins would still be calculating on a sample basis, but since they are > indipendend threads (both internal and external plugins), possibly even running on
> different CPU cores, it is well possible that they are not entirely in sync.

what?

this is a little naive, don't you think?

that's why they have buffers.

Yes, that's why they have buffers! But these buffers and the underlying algorithms have to run flawless to get everything in sync. Even the CPU cores have to be synced against each other (which was a problem with Windows XP until a patch came out). And Live does not seem to handle this like it should at the moment, because attack times do vary. I will put up some audio-files for demonstration with my next post.



Concerning Simpler and Sampler, both share the same timing bugs which I have found out more details about.

Whenever Simpler/Sampler play a note at the end of a clip that is shorter than the sample it is playing then the next note/sample will play exactly 1 ms/44 samples late.

I also found out why Simpler vs Audio track never cancels in an inversion test:

Simpler/Sampler always use "Normal" Interpolation by default and it seems that Interpolation modifies the sample even if you play it at original sample-rate. While you can switch off Interpolation in Sampler, in which case it will cancel versus an Audio Track, you cannot change Interpolation on Simpler. By the way, all Interpolation modes of Sampler modify the sample at original sample-rate. "Good" Interpolation" actually seems to be worst in this regard!

Hi,

I'm sorry, but there is too much to digest in one thread, and too many assumptions/ partial truth/ tests that need review.

First, plugin latency compensation and buffer size do work as expected in Live 6 and in Live 7, and as far as I know, they work the same. The buffer for a plugin is calculated when the plugin is created, so, yes, you need to reload your set OR delete/re-create a plugin, for a change of plugin buffer size to be taken in account.

Now, I'm not sure I get the thing with plugin buffer size and timing/attack? Do you mean that the attack time of plugins is dependent on the plugin buffer size?

For the rest, please enlighten me with less words!

Regards,
Amaury