pedx1ng wrote:EQ8 should be in High Quality mode to show the issue. There is some uncompensated delay in HiQ mode.

Ah, thanks for this addition. Yes, I tried it and it does misbehave when in high quality mode. In an actual layering scenario, a quick fix would require inserting a neutral instance of the same plugin into the other rack chain as well, to keep the chains in sync - hardly an elegant solution to the underlying problem, though, especially when doing more elaborate layering.

pedx1ng wrote:EQ8 should be in High Quality mode to show the issue. There is some uncompensated delay in HiQ mode.

Ah, thanks for this addition. Yes, I tried it and it does misbehave when in high quality mode. In an actual layering scenario, a quick fix would require inserting a neutral instance of the same plugin into the other rack chain as well, to keep the chains in sync - hardly an elegant solution to the underlying problem, though, especially when doing more elaborate layering.

That's only for this specific problem which, to be honest, is way simpler than a real life scenario. Unless you are making really simple music these issues are going to become more and more of a problem. For example, usually you put a plugin like LFOTool or volumeshaper at the end of an fx chain. If you don't have any FX between volumeshaper and your instrument then it's fairly simple, the audio won't have much delay if any. However, if you put FX between the two then you introduce delays and you have to change your envelope in LFOTool or Volumeshaper. FX chains can change many times throughout the course of producing a track, are we expected to change our envelopes every time something changes?

It's ridiculous and needs to be fixed. I honestly don't know why this is still up for debate. There are timing issues with plugins in Ableton Live and their is no excuse for them to not be fixed.

There are issues with Live 8's lack of alignment of automation and song position information to plugins which I want fixed as much as everyone else here, but there is another issue which is not very well understood, and more general that applies to all DAW users.

There is something called a "two path polyphase IIR filter" as outlined in the paper "The Design of Arbitrary-Band Multi-Path Polyphase IIR Filters" by Dr Artur Krukowski and Dr Izzet Kale, which is commonly used for oversampling. It's used in Live 8's EQ 8 in HQ mode and it's used by loads of people in the audio industry since it's low cpu and has a very steep filter rolloff. So what's the down side? In DSP there is always a tradeoff, it's this case it's the non-linear phase response. This will delay your incoming signal by somewhere from 2.x samples to 4.x samples (depending on the steepness of the design) at DC that with frequency in a non-linear way.

Ok, so what does that mean? This means if one of these polyphase IIR oversampling filters is in your signal path that you have a fractional (sub-sample) delay unit processing your entire signal, and the fraction of a sample it delays your signal increases with frequency, so there is absolutely no way you can compensate for this, other than to run ALL your other tracks through the same filter to delay them by the same amount. But hang on, it's not that easy, since if you chain three plugins, each which uses their own design of an IIR polyphase oversampling filter, then you need to reconstruct the exact same "clean" version by passing all your other audio tracks through exactly the same total chain, but without doing any processing on the signal. That is just to align two tracks together. Have different plugin chains on different tracks and it becomes impossible to correct for.

I repeat, this issue is not the sole problem of Live 8's oversampling as used in the EQ8 HQ mode, it's everywhere and it's an issue in all DAWS - but many developers keep quiet about using it since the polyphase IIR solution is cheaper in cpu and does a really good job if you don't care about your phase going out of whack with other tracks. You basically have to verify this yourself by putting a single sample spike through a plugin and see what it looks like once it's processed since developers can't even declare the delay to a host since each frequency has it's own fractional delay and hosts only take a single integer as the delay to compensate (which is fine, that should be enough!)

There is a solution, and that is to use linear phase FIR oversampling filters. Ok so what's the tradeoff for this fix? Slightly more cpu usage and more latency, but this time the latency is constant and can be corrected for by the phase so the crack of your transients all stay put and don't turn into limp plops when they phase with other parts of your track.

So in summary the polyphase IIR oversamplers do a really good job for the amount of cpu they use, and they introduce minimal latency into the signal path, but the latency they do introduce is non-linear and can't be corrected for easily, and so can cause phase issues. The FIR alternative uses more cpu and latency, but the latency is constant and can be corrected for. So either way it's a bummer.

A much better solution is to run your entire project at 88.2 khz or 96 khz, then you don't need to oversample in individual plugins, and all your EQ shapes are very analog like in shape and phase, and your aliasing is reduced across the board so all your mixes are clearer and tighter. If the oversampling can be bypassed in your plugins (which I allow in mine by not all developers support) then there is no extra latency introduced so nothing needs correcting for. The cost here is increased CPU usage across the board as well, with every single plugin taking twice as much cpu.

Last edited by andy-cytomic on Tue Oct 23, 2012 10:51 pm, edited 1 time in total.

Cheers Andy, Very useful information and even I understand it Still it is a pot luck/lottery then whether or not sounds turn out as they should then and well I don't use Live for multi-track recording but still if its everywhere then it makes no odds and I might as well sod spending so long painstakingly positioning and then re-positioning microphones like dw above...Nah I won't but obviously a re-evalution is needed and with the power on tap these days it would make sense to go for the option where more CPU and latency are an issue than russian roulette

Looks like I'm sticking at 88.2 which I was at and was not planning to change.

Live 9 I'm in anyway but great to see/hear some of the new devices.

Regarding non-ellegant solutions even though its not Live...Long time Pro Tools user along with other friends/people I know whom use Live also and prior to version 8 well...enough said unless we were at work on one of the HD rigs, Medieval times yet still rather medieval if improvemets could be implemented but are not for being cheap

andy_cytomic wrote:I'm glad I'm not the only one that worries about sample accuracy!

...

A much better solution is to run your entire project at 88.2 khz or 96 khz, then you don't need to oversample in individual plugins, and all your EQ shapes are very analog like in shape and phase, and your aliasing is reduced across the board so all your mixes are clearer and tighter. If the oversampling can be bypassed in your plugins (which I allow in mine by not all developers support) then there is no extra latency introduced so nothing needs correcting for. The cost here is increased CPU usage across the board as well, with every single plugin taking twice as much cpu.

Would we get same benefit is we choose oversampling on individual plugs in render modes, but still worked in 44.1?

It depends on the project. If you only oversample a couple of times it is more efficient to work at 44.1 khz and then oversample only the plugins you need, but this introduces latency, which Live 8 does not compensate for properly in terms of song position information to plugins, and automation to plugins after the latency introduction plugin.

dusted william wrote:Is there a DAW that you know of that doesn't have this problem?

looks like I'm going back to running things in 96 khz

dw

Which problem do you mean? If you mean the non-linear phase of polyphase iir oversampling filters then every DAW will suffer from this, and it's not really the DAWs fault, it's the plugins fault as it can't be corrected for. But for plugins that introduce integer sample latency (eg lookahead compressors, or linear phase oversampling plugins) DAWs should be able to send song information and automation in a sample accurate manner to plugins, otherwise I would say this is a bug in the DAW that needs fixing.

I've just done some investigations in the song position information and automation in Live 8 (which is the DAW that I use and love). I believe that knowing what is going on is always useful, so hopefully this will help you adjust your automation and manual delay compensation so you can get sample accurate results when using Live 8.

I added a 20khz sine wave to a new project and inserted 3 plugins: The Drop then two copies of The Glue, all on the same track. I set up The Drop to use song position information to trigger the synced LFO and make sharp stabs once per second in the audio. The host temp was 120 and I froze the audio and copied it out each time (a very cool feature!) I then moved the position of The Drop to second in the track and repeated, and again in third position.

What I found is each vst / au plugin (not inbuilt Live ones) before the one that needs song information / automation generates a single audio buffer size block of latency, which results in the song position and automation getting passed to the plugin a multiple of the audio buffer size block early. I double checked by setting the audio buffer size to different amounts and repeated the steps.

So the formula is:

song position and automation advance in samples = (number of 3rd party plugins on track before the one that needs sample accurate song pos and automation) * (audio card buffer length)

and if there is extra latency introduced by linear phase oversampling then the formula is:

(edit: in the below, I have changed "audio card buffer length" to "plugin buffer size", which defaults to "as audio buffer" but can be set to something different, so it is the one that is needed for the forumula)

song position and automation advance in samples = (number of 3rd party plugins on track before the one that needs sample accurate song pos and automation) * (plugin buffer size) + (latency of all 3rd party plugins on the track before the one that needs sample accurate song pos / automation)

So if you have sharp automation then you have to delay the steps position by a number of samples that dependends on both where the plugin is in the chain and your audio buffer size, so if you change either you'll need to update your automation as well. I hope that helps!

PS: the automatic PDC in Live 8 works perfectly, it nulls with two tracks in parallel, so any latency introduced by linear phase oversampling is completely corrected for. The above only refers to automation and song position information being sent to plugins (and possibly midi being sent to effects plugins not first in the chain too, but I've not checked into that so I don't know for sure).

Last edited by andy-cytomic on Sun Oct 28, 2012 9:03 pm, edited 1 time in total.

coroknight wrote:Unless you are making really simple music these issues are going to become more and more of a problem.

A bit of a low blow, don't you think?

andy_cytomic wrote:There is a solution, and that is to use linear phase FIR oversampling filters. Ok so what's the tradeoff for this fix? Slightly more cpu usage and more latency, but this time the latency is constant and can be corrected for by the phase so the crack of your transients all stay put and don't turn into limp plops when they phase with other parts of your track.

Andy, first of all, thanks a ton for your informative input on this!

Secondly, yep, I realized this is exactly why the specific issue of parallel chains hasn't been bothering me: I rechecked with all my mainstay plugins, and every single one of them passes the parallel chain sync test. For example, Pro-Q is my go-to EQ, no problem whatsoever in any mode; zero latency or high quality linear phase modes. Same thing with everything else. I never use Live's built in EQ, for example. Not a choice originally based on this particular issue, but I just happen to use stuff that works in this context - oh, and also routinely run my projects in 88.2 kHz these days.

However, I fully understand how situations with plugins like VolumeShaper can be a pain. I have occasionally had the need to offset automation (that is, the native Live automation envelopes) on tracks that introduce a lot of latency, and this is indeed what needs fixing the most: automation should be synced consistently with PDC.

song position and automation advance in samples = (number of 3rd party plugins on track before the one that needs sample accurate song pos and automation) * (audio card buffer length)

and if there is extra latency introduced by linear phase oversampling then the formula is:

song position and automation advance in samples = (number of 3rd party plugins on track before the one that needs sample accurate song pos and automation) * (audio card buffer length) + (latency of all 3rd party plugins on the track before the one that needs sample accurate song pos / automation)