Plug-in phase drift w/ heavy processor loads - IOW: PLUG-INS SUCK!

[SiliconAudioLab]

What I’m talking about is the instability of plugs under varying and heavy processor loads and phase shifting from say a lead vocal or in my case often the actors/dialog tracks when stemming them out.

I'm telling you that depending on your load the plugs processing shifts in phase at certain frequencies. Slowly over time the phase will roll (during playback or course). You would think Digide$ign had compensated for this using their multiple DSP chips on the cards. But my theory is once they get taxed they too drift in accuracy. I mean look, the DSP of eq is all about subtle delay in macro levels at certain frequencies.

Instanciate a bunch of plugs until your computer throws the warning that CPU or TDM is near maxed. Then pull in a movie and see if things don't change.

It’s a slippery devil and it’s not freakin’ VERTIGO!

Once I get a spare millisecond second I’ll do more null testing myself. We should all be fully aware of how free running LFO’s in soft sytnths are not locked. I’m not including any soft synths or reverbs when this happens.

Start with a main vocal track.

I suggest is to instanciate many plugs in that one channel. Start w/ a focusrite plug then maybe channel strip or a ren vox compressor add a de-esser and maybe a throw in C4 for kicks in the main vocal track AND the other tracks.

Now add more plugs to other channels until a warning is thrown. Those tracks don’t have to have audio but even better if they do. Add those audio tracks WITH the extra plugs processing away. Now open a QT movie and see if things don’t start to slip with a null test.

I’ll use dozens and dozens of instances WITH Altiverb! Fine - take Altiverb out of mix by bypassing it but leave it instanciated.

I further suspect that even without a movie the problem exists at such a subtle level that when we are slamming big mixes we miss it.

The other way you could do this is to solo the vocal in/out with all those extra plugs in then null with them all removed completely (un-instanciated) except the main ones in the vocal track which need to be muted. Yes I'm factoring in plug processor delay (usually 3~7 milliseconds).

[SiliconAudioLab]

Here's more info I posted in a more...um....whacky thread:

I get movies all the time in Logic. If I use plugins things start sounding time/phase drifted. Different frequencies drifting in time and the phase getting whacky. EQ's/De-essers/Oxford/Waves/ProTool$/Logic different DAE memory allocations - still creeps up. Depending on the amount of compression in the movie and at certain parts of the movie multiplied by how many instances I have will yield different results. All of it a moving target.

NONE of it reproducible on a consistent basis! Three different G4's (Silver Mirror - ram maxed), G5's (ram maxed) Mix+, HD 44.1 48, and 88 worse at 96K! Some days after a fresh boot you don't hear it. The ol' cntrl/optn/p/r reboot on the OS 9.22 machines won't clear it.

As the movie loops (& potential memory holes develop) the problem slowly shows up. But I don't think it's ram frag. It's so damned subtle it's impossible to track. Changed all the clocks/termination/cables/sources of clocks etc... Same results. Mostly. Mostly.

I've talked to roundbadge about this once and the issue I believe is PROCESSOR LAG!

It's what drove me to GearSlutz & to start reacquiring the hardware gear again. I'm STILL tuning the room thinking THAT could have been it. Headphones - same result. Mostly.

Plug-ins suck. Mostly. Sorry. They do. I'll start another thread on this.

[Kiwiburger]

I can't comment on Protools - but i've done a few torture tests in Cubase SX3 and haven't been able to detect any problems in null tests.

I'm the sort of person who gets insulted at KVR for commenting about phase anomolies with certain plugin makers who are worshiped over there.

But if you go to analog gear, you get more phase anomolies - not less. So the real issue is whether your ears like what you hear or not.

Maybe this is timely reminder to freeze or otherwise render effects individually, so the CPU isn't stressing at mix time.

[dkatz42]

Processor load *shouldn't* (carefully qualified) make any difference on any of this--phase, timing, whatever, so long as the DAW is reasonably sane.

Think of it as an assembly line, with a bunch of samples coming along a bunch of different conveyor belts. At the places where parts come together (busses, sidechains, etc.), the partially-assembled mass stops and waits for all of the parts to show up before moving on to the next station.

Under normal circumstances, the line can move faster than the average required (the output sample rate.) So a bunch of completed assemblies pile up in a queue (the output buffer) and the whole thing comes to a halt until the queue opens up a bit (samples are clocked out.)

Under enough load, the assembly line falls behind; if the output queue empties, you get pops and clicks or the software quits.

But the important thing to note is that instantaneous timing should *not* be an issue, as the only place where time is even considered is at the D/A. No jitter is possible in the purely digital world.

It's slightly more complicated when there is A/D in the picture; it just means that the assembly line comes to a halt either when the output buffer fills or the input buffer empties. As long as the output buffer is never empty, nor the input buffer is never full, things will work. The combination of the two buffers defines the elasticity of the system. (This is also why your A/D and D/A need to run off of the same clock; otherwise you are guaranteed to eventually overrun or underrun if one is slightly faster than the other.)

The phrase "processor lag" simply makes no sense. If the processor has enough capacity (in combination with the elasticity of the buffering) to keep up, then by definition all the work will get done and things will work. If it falls behind far enough, the output buffer runs dry and the whole thing grinds to a halt. There really isn't any middle ground.

For the same reason, faster-than-real-time bounces (that don't utilize outboard processing) should be absolutely identical to real-time bounces.

This is not to say that software doesn't have bugs, of course.

[iluvatar]

Originally Posted by dkatz42

Processor load *shouldn't* (carefully qualified) make any difference on any of this--phase, timing, whatever, so long as the DAW is reasonably sane.

Think of it as an assembly line, with a bunch of samples coming along a bunch of different conveyor belts. At the places where parts come together (busses, sidechains, etc.), the partially-assembled mass stops and waits for all of the parts to show up before moving on to the next station.

Is that actually how DAW's are set up? I should find some white papers or something on this, but I don't see how the software can be constructed like this and still have plug-in/buss latency be an issue. Plug-ins run in their own separate processes and if they were all sync'd like this, then the system would automatically compensate for the time it takes to process them. If your CPU can't keep up, then you get drop outs. If it can, then everything is fine. We shouldn't have the in-between scenario where plug-ins lag, but drop-outs don't occur. But that's what we get often times.

-Dan.

[SiliconAudioLab]

Originally Posted by iluvatar

Is that actually how DAW's are set up? I should find some white papers or something on this, but I don't see how the software can be constructed like this and still have plug-in/buss latency be an issue. Plug-ins run in their own separate processes and if they were all sync'd like this, then the system would automatically compensate for the time it takes to process them. If your CPU can't keep up, then you get drop outs. If it can, then everything is fine. We shouldn't have the in-between scenario where plug-ins lag, but drop-outs don't occur. But that's what we get often times.

-Dan.

Yep thanks Dan - I was thinking the same thing. There are thousands of processes going in MANY different worlds and circuits and cards - like the 4 Motorola’s (I think they are MOTO's) DSP’s in one of my Digi cards. The Time Duplex Multiplication process of Digi's TDM is in itself not entirely built this way either.

Then you bust into the code of the plug makers themselves - which is where I think the REAL CULPRIT LIES!

They're fine for processing your, say, a de-esser under ideal circumstances but push things and frequencies start getting whacked and start drifting. It's soooooooooooooo unbelievably subtle it's like herding cats.

Thing is, once I swap it out into analog - like with a de-esser (I'm using a good one - a dBx 902 which is not completely colorless) there's no phase frequency drift anomaly.

[iluvatar]

Originally Posted by SiliconAudioLab

They're fine for processing your, say, a de-esser under ideal circumstances but push things and frequencies start getting whacked and start drifting. It's soooooooooooooo unbelievably subtle it's like herding cats.

I don't think this could cause specific frequencies to "drift" more than others, at least not in the digital world. What I do think is that the whole signal could be time-shifted a certain degree and that when summed with the original signal, the particular frequencies most notably effected by the time shift would depend upon the magnitude of the delay.

-Dan.

[max cooper]

Originally Posted by djui5

This is funny because I was noticing this the other day. My mixes sounded slightly different when the CPU is being heavily taxed. If I close the session and bring it back up it's slightly different sounding.....

I thought I was hearing things.

DJ:

Are you saying that if you close the session and re-open it without changing anything, that the CPU load is less? Because I've been noticing this too.

I haven't heard the sonic difference, but maybe my ears are tin. But the CPU decrease I've noticed..

[Ghost Logic]

I think I have also noticed this in Logic Pro--when I bounce a bus channel with heavy plugin loads(frequently a comination of several individual channels with multiple plugins per channel), the bounced audio track ends up sounding more "solid" and less phasey than the bus channel where the plugins were running in realtime. I never really understood why the bounced audio sounded more solid (particularly given that it was dithered from 32 bit down to 24 bit), but perhaps the lack of processor load dependant phase issues explains it.

[SiliconAudioLab]

Originally Posted by iluvatar

I don't think this could cause specific frequencies to "drift" more than others, at least not in the digital world. What I do think is that the whole signal could be time-shifted a certain degree and that when summed with the original signal, the particular frequencies most notably effected by the time shift would depend upon the magnitude of the delay.

-Dan.

The thing is most DSP uses quite a bit of band splitting in the process to do it's thing. I was shocked when a propeller head at Digidesign was showing me his work on the EQ. EQ!?!? Yep they split up the bands in many points & use delays just to get the eq to do it's crazy phasey thing. Now I'm not talking about the "bands" we see - ya know: L/LM/M/HM/H.

I'm talking about the process that gets the EQ to the point where it has certain "characteristics" and does it's intrinsic thing.

Now think about all the other Plugs and variations of signal processing. From what I understand DSP for almost all plugs involves some form of band splitting.

Just to be clear to all - this drift is super subtle and slow. Like a long sine wave through the song effecting certain frequencies in time on the track or plug in question.

Sometimes the sweeps are faster sometimes slower and longer.

[SiliconAudioLab]

It got so bad that years ago I started pulling every single individual track out of the Digi hardware (short BEEFY lightpipe cables) into a Sony DMX-R100 (& 2 previous digital mixers) and I mix there.

I'm running PT6 & Logic 6.4 ~ 7 Pro on Digi hardware.

[Kiwiburger]

Offline rendering can take as long as it takes, and everything (in theory) is fully sample accurate. Of course, some plugin algorithymns make use of band splitting and delays in order to re-create the phase shifts that we like to hear in analog gear. But they should be, in theory, be consistent when rendered. But they probably use some tricks for fast realtime use - and maybe things slip a bit when CPU load is high.

I'm a big fan of 'Audio Processing' in Cubase. That's where you can apply a plugin offline, and free up CPU while mixing. I don't like 'Freeze' - seems a bit clumsy to me.

[dkatz42]

Originally Posted by iluvatar

Is that actually how DAW's are set up? I should find some white papers or something on this, but I don't see how the software can be constructed like this and still have plug-in/buss latency be an issue. Plug-ins run in their own separate processes and if they were all sync'd like this, then the system would automatically compensate for the time it takes to process them. If your CPU can't keep up, then you get drop outs. If it can, then everything is fine. We shouldn't have the in-between scenario where plug-ins lag, but drop-outs don't occur. But that's what we get often times.

-Dan.

There are lots of separate processes, but they most definitely must have sync points. The system does automatically compensate, or it wouldn't work at all. The art of building any parallel processing system is to tease out the parts that can run in parallel for as long as possible without blocking, but eventually they all have to block. The Logic Node is a good example of a loosely-coupled parallel process. The various restrictions on what you can and can't run on a Node illustrate the synchronization issues.

If there are artifacts in the sound that appear to be load-related (and I will defer to those that hear them, even if I don't) it could be a developer trying to get fancy and doing something to speed up the process (at a sonic cost) rather than rolling over and dying, or it could be a bug (wouldn't be the first one, nor the last.)

[SiliconAudioLab]

Originally Posted by dkatz42

There are lots of separate processes, but they most definitely must have sync points. The system does automatically compensate, or it wouldn't work at all. The art of building any parallel processing system is to tease out the parts that can run in parallel for as long as possible without blocking, but eventually they all have to block. The Logic Node is a good example of a loosely-coupled parallel process. The various restrictions on what you can and can't run on a Node illustrate the synchronization issues.

If there are artifacts in the sound that appear to be load-related (and I will defer to those that hear them, even if I don't) it could be a developer trying to get fancy and doing something to speed up the process (at a sonic cost) rather than rolling over and dying, or it could be a bug (wouldn't be the first one, nor the last.)

Well put. But remember the anomalies that occur during production always magically "disapear" or become "usable" as ship date nears. There used to be a saying here in the Silicon Valley: "SIFI" (ship it - f*** it!) and the alltime fav: "next rev."

[iluvatar]

Originally Posted by dkatz42

There are lots of separate processes, but they most definitely must have sync points. The system does automatically compensate, or it wouldn't work at all. The art of building any parallel processing system is to tease out the parts that can run in parallel for as long as possible without blocking, but eventually they all have to block. The Logic Node is a good example of a loosely-coupled parallel process. The various restrictions on what you can and can't run on a Node illustrate the synchronization issues.

If there are artifacts in the sound that appear to be load-related (and I will defer to those that hear them, even if I don't) it could be a developer trying to get fancy and doing something to speed up the process (at a sonic cost) rather than rolling over and dying, or it could be a bug (wouldn't be the first one, nor the last.)

I haven't done any real parallel or plug-in programming myself, so I don't know the ins and outs of thread synchronization. Please excuse my ignorance, but why aren't the threads/processes (and various signal paths) in audio apps sync'd perfectly? Is this even possible?

I haven't noticed this drift that SiliconAudioLab is talking about, so I can't theorize about it. What I have experienced on a couple different platforms that, as far as I know, feature plug-in latency compensation, is a latency/phase problem when using parallel compression. For example, say all your drum tracks are routed to the master outputs and also via an aux to a separate buss/fx channel, which is then routed to the master outputs. At this point there may or may not be any noticeable problems, but if you throw a compressor plug-in on the buss, there will be a definite audible effect on the phase coherency of the two signals.

-Dan.

[dkatz42]

Originally Posted by SiliconAudioLab

Well put. But remember the anomalies that occur during production always magically "disapear" or become "usable" as ship date nears. There used to be a saying here in the Silicon Valley: "SIFI" (ship it - f*** it!) and the alltime fav: "next rev."

Heh . 14 years in the valley, I know it well. One of the reasons I left my previous employer (now an extremely large and well-known networking company) and went with a startup. Had a sort of exit interview with the CEO, who wanted to know why I was leaving (as part of a torrent of senior engineers): "We're shipping crap."

[SiliconAudioLab]

See my new signature!