Zebra 2.2 VST vs AU CPU spikes

[pgmvdm]

Some presets of the VST version of Zebra 2.2 cause occasional high CPU loads ("Spikes") on my Macbook Pro. I installed both the VST and AU version of Zebra and did some testing with three different hosts using the "HS DY7 Add Pad" preset.

In both Cubase and Live the "HS DY7 Add Pad" causes the audio to drop from time to time. I play the preset "piano style" using a sustain pedal. When the audio drops the VST performance meter of the host goes to 100%. When playing normally the VST performance stays between 40 and 50 percent. The audio drops are intermittent and there can be anything between 5 seconds to a minute between them. There does seem to be a positive correlation between CPU load and the frequency of the Spikes. Sometimes a spike can last over a second - much more than a buffer worth of audio. I used the same audio settings in both VST hosts: 44100 Hz with a buffer size of 512 samples.

When using the AU version of Zebra from GarageBand with the same patch I have no problems with dropping audio at all! I don't know what buffer size GarageBand uses but sounds like somewhere around 512. The sample rate is 44 kHz.

I have no problems with other VST's like Pianoteq or Korg M1.

System: Macbook Pro 2.2 GHz 4 GB, MAX OSX 10.4.11, M-Audio Firewire Audiophile
Cubase Studio 4.1.2, Live Lite 6.0.10, GarageBand 3.0.4

Any ideas on what could be the cause of this?


Pieter.

[Urs]

AFAIK it's a general problem with Cubase. I also got spikes / drop outs with their built in instruments... I think I have successfully configured my ASIO driver on Windows to not get spikes with Cubase 4 anymore, but havn't tried it on MacOS X.

Anyone?

[pgmvdm]

AFAIK it's a general problem with Cubase. I also got spikes / drop outs with their built in instruments... I think I have successfully configured my ASIO driver on Windows to not get spikes with Cubase 4 anymore, but havn't tried it on MacOS X.

Anyone?

The other plugins I use, Pianoteq, Korg M1 / Wavestation, and the Cubase plugins, HalionOne and Prologue, all work fine. If I push things too far I get 'ticks'. Zebra behaves different in that the audio drop-outs are much longer and that it occurs at low loads.

I tried different combinations in Cubase of the "Multi Processing", "Audio Priority"
and buffer size audio options. But I always get the same drop-outs even at a buffer size of 2048.

The reason I think that it is a Zebra/VST related issue is that I get the same behaviour when I use a different VST host (Ableton Live) but when I use the AU version of Zebra from GarageBand it works fine.

Does anyone with a similar setup have the same problem?

Pieter.

[audioaquatic]

CPU spikes in Tiger are well-documented. It is fixed in Leopard.

[Urs]

I wouldn't rule out a flaw on my side. I'm just puzzled because the code is literally identical except for the API-specific stuff (AU/VST). Which is less than 1% of the code.

I'll perform some tests...

[mkelly]

The reason I think that it is a Zebra/VST related issue is that I get the same behaviour when I use a different VST host (Ableton Live) but when I use the AU version of Zebra from GarageBand it works fine.

Does anyone with a similar setup have the same problem?

I have a similar setup: Macbook Pro 2.2 GHz 4 GB, OSX 10.4.11, but with an Audio Kontrol 1. I do not yet own Zebra 2, but have experienced similar issues with Zebra CM using Ableton Live 6 and 7. I also tried it with other plugins that I could get in both VST and AU formats.

To recap my experiences, using VSTs caused disk spikes whereas the AUs of the same plugins caused no such disk spikes. Note that I got CPU spikes indicated in Live, but when I used the Apple system monitor tool (and iStat) they indicated spikes in disk activity as opposed to CPU. I also used a tool to monitor disk activity called "fs_usage" - I noticed that when using a VST there were massive numbers of filesystem accesses by the "loginwindow" process - these did not happen for the AUs.

Check your own system when doing using VSTs (run Activity Monitor and in a terminal try "fs_usage | grep loginwindow") to see what I was talking about above. I'd be interested to see if it's a similar issue.

Cheers,

mo

[pgmvdm]

Check your own system when doing using VSTs (run Activity Monitor and in a terminal try "fs_usage | grep loginwindow") to see what I was talking about above. I'd be interested to see if it's a similar issue.

Cheers,

mo

I did some tests and can confirm this behaviour: Massive amounts of IO is logged by fs_usage from both the loginwindow process and the VST host process when a preset that exhibits the audio drop out issue is playing. Both Cubase and Live have the same behaviour. When using GarageBand no IO is generated.

When one of the presets with the issue is sounding there is about one IO logged every millisecond. When there is no sound or when a different preset is selected there is no increased IO. None of my other plugins cause this kind of IO.

I also noticed that every time an audio drop out occurs some disk disk activity is shown in Activity Monitor.

Some presets with increased IO (and drop outs): HS Acidophilus+, HS Almost Strings+, HS Schhh, HS Creamery
The "HS Clavicomb" presets causes increased IO as well, but much less.

Below is the output from fs_usage around some disk IO that IMO correlated to an audio drop out:

Code: Select all

22:04:12.893  write           F=1    B=0x16                        0.000005   Live                
22:04:12.894  write           F=1    B=0x16                        0.000005   Live                
22:04:12.894  write           F=1    B=0x16                        0.000004   Live                
22:04:12.894  write           F=1    B=0x16                        0.000004   Live                
22:04:12.894  write           F=1    B=0x16                        0.000005   Live                
22:04:12.905  write           F=1    B=0x16                        0.000300 W Live                
22:04:12.905  write           F=1    B=0x16                        0.000005   Live                
22:04:12.917    WrData        D=0x00001bf0  B=0x200  /dev/disk0s2  0.000514 W update              
22:04:12.921    WrMeta[async] D=0x00000002  B=0x200  /dev/disk0s2  0.000445 W update              
22:04:12.921  sync                                                 0.498111 W update              
22:04:12.922    WrMeta[async] D=0x000013c0  B=0x1000 /dev/disk0s2  0.000836 W update              
22:04:12.922    WrMeta[async] D=0x00009bf8  B=0x1000 /dev/disk0s2  0.001290 W update              
22:04:12.923    WrMeta[async] D=0x00063230  B=0x2000 /dev/disk0s2  0.001727 W update              
22:04:12.923  write           F=8    B=0x400                       0.089544 W loginwindow         
22:04:12.923  write           F=1    B=0x16                        0.017844 W Live                
22:04:12.923  write           F=1    B=0x16                        0.000006   Live                
22:04:12.923  write           F=1    B=0x16                        0.000004   Live                
22:04:12.924    WrMeta[async] D=0x00063410  B=0x2000 /dev/disk0s2  0.002464 W update              
22:04:12.924  write           F=1    B=0x16                        0.000004   Live                
22:04:12.924  read            F=9    B=0x400                       0.000815 W loginwindow         
22:04:12.924  write           F=8    B=0x400                       0.000007   loginwindow         
22:04:12.924  read            F=9    B=0x5b                        0.000002   loginwindow         
22:04:12.924  write           F=8    B=0x5b                        0.000003   loginwindow         
22:04:12.924  write           F=1    B=0x16                        0.000005   Live               
 

Pieter.

[Urs]

Interesting! What is this?

I'm still stunned as to why the VST versions should exhibit spikes while the AU versions do not. My plugin compatibility layer is no more than a thin surface of code that translates messages to and from my engine, back and forth. None of these layers shall ever consume more time than a fraction of a microsecond, never enough to cause a cpu spike.

There used to be spikes when people hit the play button because Zebra would reset its delays and stuff. But even that's pretty much gone by now.

I suspect there's more behind it and I'll put it on the table next time I meet a host developer...

Later,

Urs

[mkelly]

Both Cubase and Live have the same behaviour. When using GarageBand no IO is generated.

A good example is when you use Live to host the AU - you should see no spikes. It's the same host, so the only difference is the VST vs AU.

I'd like to re-iterate that I see this with more than just ZebraCM. So it's not Urs' problem. However, it's good to bring it to his attention cause he might just be able to find out what's going on more than mere mortals can!

Cheers,

maurice

[mkelly]

I'm still stunned as to why the VST versions should exhibit spikes while the AU versions do not. My plugin compatibility layer is no more than a thin surface of code that translates messages to and from my engine, back and forth. None of these layers shall ever consume more time than a fraction of a microsecond, never enough to cause a cpu spike.

I could understand disk activity, but why it seems to revolve around the "loginwindow" process seems bizarre. I notice that both I and Pieter are running 10.4.11 - I wonder is this behaviour the same in Leopard?

BTW - what we both see is a disk spike, rather than a CPU spike. Live indicates a CPU spike, but the Apple Activity Monitor shows abnormal disk activity at the same time, with no corresponding CPU spike.

Cheers,

maurice

[Urs]

It's really interesting.

The disk spikes hint at paged out memory. That is, RAM allocated to the software has been written to disk and then taken back in (formerly known as virtual memory).

Maybe there's a difference in the way AUs and VSTs are loaded into RAM. And for some reasons maybe VST data is easier paged out than AU data? Hardly believable, but some knowledgable might be able to find out...?

What you could do is, open Terminal.app and type "top", then press enter. In teh first batch of information there's a counter for "pageins" and "pageouts". If this changes with the spikes, we're closer to the problem!

Cheers,

Urs

[mkelly]

It's really interesting.

The disk spikes hint at paged out memory. That is, RAM allocated to the software has been written to disk and then taken back in (formerly known as virtual memory).

Yeah - I thought about that too. I also wondered about things like Spotlight (there's an md<something> program that runs in the background collecting info I believe. I notice Pieter has 4Gb of RAM - surely he'd need to be running a lot of apps to cause paging to occur. I was running on 2Gb of RAM when I noticed the problem first. Haven't been using VSTs since (and recently upgraded to 4Gb). However, in that 2Gb, I was running only Live and one track with ZebraCM (or other VST) on it. BTW - the other VST I tested extensively with was LinPlug's AlphaCM.

What you could do is, open Terminal.app and type "top", then press enter. In teh first batch of information there's a counter for "pageins" and "pageouts". If this changes with the spikes, we're closer to the problem!

I'll attempt that tonight when I get home - don't use the Mac at work unfortunately.

Cheers,

maurice

[mkelly]

What you could do is, open Terminal.app and type "top", then press enter. In teh first batch of information there's a counter for "pageins" and "pageouts". If this changes with the spikes, we're closer to the problem!

I'll attempt that tonight when I get home - don't use the Mac at work unfortunately.

Unfortunately I can't reproduce this now. The only major difference is that I'm now using 4GB of RAM. I still see the loginwindow accesses when loading VSTs in Live. I also see them when changing presets in ZebraCM (though not Zebra2).

Sorry I couldn't reproduce this. Honestly wasn't making it up

Cheers,

Maurice

[Urs]

Hmmm... no idea what loginwindow's role would be in there...

It's like MFM2 which might crash in Live when it's in the root library folder. Put it in your user lib folder and it never crashes.

Bizarre... computer science sometimes comes close to the realm of spiritual...

[pgmvdm]

I did some more testing following the trail of the fs_usage reported by Maurice.

When I run Cubase from a terminal window window the following messages are logged:
* Add instrument track with Zebra2

Code: Select all

setSampleRate
Resume
Resume

* Edit Instrument

Code: Select all

ey, getting teh rect now!
Eeek, AM_FileErr AM_View_Interface::scanPresetFolders 4
ey, getting teh rect now!
editVST->sizeWindow ( 800, 590 );
resize failed!

* Select preset: "HS DY7 Add Pad"
* play note

Code: Select all

AM_VST_View_Interface::nativePresetChanged( HS DY7 Add Pad )DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
DelayNaN4: LimitCoeff
...

The "DelayNaN4: LimitCoeff" lines appear at (approximately) the same rate as the fs_usage log lines.

When I start Cubase from a terminal window I get no audio drop outs. The output from fs_usage in this case looks like this:

Code: Select all

20:09:10.643  write   F=1    B=0x16    0.000047 W Cubase Studio 4     
20:09:10.643  write   F=1    B=0x16    0.000007   Cubase Studio 4
20:09:10.643  write   F=1    B=0x16    0.000005   Cubase Studio 4
20:09:10.643  write   F=1    B=0x16    0.000004   Cubase Studio 4     
20:09:10.643  write   F=1    B=0x16    0.000004   Cubase Studio 4

When I change the "Global/FX" Reverb1 parameter in the preset "HS DY7 Add Pad" from Reverb to MetalVerb get only a few messages while the audio is fading. When I change the parameter back again I get all the messages again.

Could it be that Zebra is writing to stdout and that when no terminal is available the loginwindow process (which launches the dock?, which in turn launches Cubase) is the recipient? And that when stdout blocks, the audio processing blocks as well.

Pieter.