Phat Riffioso
Joined: 05/08/03
Posts: 498
Loc: London
|
The infamous save and reload 'performance droop'
#348919 - 04/09/06 08:11 PM
|
|
|
I have been looking into Tafkat's work on the performance droop when reloading projects on
certain audio hardware (well everything except lynx).
He documented how the
Nuendo based blofeld test showed a reduction in the amount of plugins a project could run
if it was saved and reloaded. The reduction gets worse the lower the latencies you work
at. The only way to reduce this effect is to improve the way your audio hardware talks to
your sequencer, in short by installing better drivers.
I have extended this
test to see what other factors can affect this performance droop and if there are any ways
to remedy it bar installing new drivers.
The droop seems to happen regardless
of what plugins are used. Tafkat used the Magneto plug-in in his test but I have found the
waves IR1 suffered from this droop even more severely so I will use this as the base of my
tests.
Test setup
Cpu: Conroe e6600 @ 3.42ghz (should really be
stock speeds)
ddr 760 at 4,4,4,12
Asus P5w DH with 1101 bios
RME
Fireface
TI firewire controller
Windows XP sp2
All latest drivers as of
September 06
Audio at 44100 kHz, 24 bit
Buffer set to 64samples
Multiprocessing turned off
Certain application require you to set a playback
buffer as well so this is set so 2x64 which is what Cubase uses internally.
I
created a test project containing several copies of an audio track. I would then add as
many waves IR1 plugins to the tracks as possible and noted when dropouts would occur. i
saved the project then reloaded the project and noted how many IR1's would need removing
for stability.
Cubase sx3 could take
29 VST instances
29 DX
instances
On reload this would drop to
17 VST
17DX
Ableton
28 VST
Reload 17 VST
SAW demo
17 DX
Reload
17vst
Samplitude 8.0.1
30 DX
Reload 17
Sonar 5 demo
29 DX
Reload 17
So the reload performance of each app is the same.
Except for SAW the initial performance is also similar.
VST plugins are as efficient
as DX plugins.
What’s interesting is that all applications except for SAW show
a few sings of drop out before the maximum plugins was meet. Drop outs would occur as
early as 17 plugins were loaded and they would disappear around 24 then reappear at the
top again. I assume this is why SAW only reaches 17 plugins because playback would stop as
soon as a dropout was sensed even if it was only 1 sample per 1 million. if this
protection was bypassed you could gain performance in the expense of stability.
Cubase was a real tough app to find the performance limit. it would peak at 27 plugins
but if you kept disabling some and adding more I could coax it up to 29.
I also
found out you don't need to reload a song to cause a droop. Changing latency back and
forth and reloading the driver would also cause this. Additionally once a droop had
occurred it could be fully recovered by disabling all the plugins and then reenabling
them.
So what is going on?
This is pure speculation but It seems to
me that the audio driver is not organising the audio threads from the application to the
processor. By reloading the project the threads are thrown out of order which is using up
extra cpu cycles . When the plugins are disabled and reenabled the threads are reordered
more efficiently saving on cpu cycles and improving efficiency.
The question is
why have lynx got it right and all the other manufactures not?
Also some
useful info here
http://www.soundonsound.com/forum/showflat.php?Cat=&Number=346139&page=1&v
iew=collapsed&sb=5&o=7&fpart=1#346139
--------------------
Kasha - Picture a beautiful life
|
Martin Walker
Watcher Of The Skies
Joined: 28/02/01
Posts: 12487
Loc: Cornwall, UK
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#349222 - 05/09/06 11:16 AM
|
|
|
Hi PhatRiff!
Perhaps you ought to be posting on Vin's (Tafkat's) own forum
for his DAWbench test at http://dawbench.vze.com. Vin does occasionally pop in here, but is
involved in so many other forums that he might only spot this if I alert him, and he'll
certainly be interested to read your results!
Other plugins were apparently
tried during the development phase of DAW bench (to ensure that Magneto wasn't skewing
cross-platform figures by favouring Intel or AMD processors). As I understand it Magento
was retained for this Cubase SX/Nuendo benchmark because it was bundled with these
applications and therefore everybody would have it to run the tests themselves.
By using Waves IR1 you have been able to duplicate your tests with different sequencers,
and I don't think anyone else has yet documented this same problem across five different
sequencer applications - well done that man! 
However, Magneto does have the advantage of having a
comparatively small CPU drain, so the numbers of plugins you can run is much greater than
with IR1, and with larger numbers the accuracy therefore becomes greater.
Reloading vs changing latency has already been documented as a problem, and the reason
for re-launching the application and then loading the song is that this seems to
completely re-initialise the audio drivers, whereas sometimes changing latency doesn't do
the trick completely, even if you use the Cubase SX reset button.
I don't
think I've spotted before on other DAWbench threads that completely disabling all plugins
and re-enabling them one by one cured the droop, although this would make sense, since
you're re-creating the original conditions. The only difference is that you're relying on
the application to completely release these plugin resources as each plugin is temporarily
disabled.
Your suggestion about the audio driver re-ordering threads more
efficiently is an interesting one - perhaps Lynx Audio could tell us whether this is the
likely reason why their soundcards seem to be the only ones that don't suffer from reload
droop, although I wouldn't hold your breath 
Whatever the cause, it's certainly an incredible frustration
that projects that worked perfectly when you save them at the end of one working day won't
run without severe glitching when you reload them the next.
Martin
--------------------
YewTreeMagic
|
TAFKAT
member
Joined: 08/01/03
Posts: 130
Loc: Australia
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#352738 - 12/09/06 10:36 PM
|
|
|
Hey PhatRiff,
Again, thank you for your time and energy.. :-)
Sorry I haven't replied earlier.. lots on.. :-)
Your results have qualified
that the performance droop is not specific to just Nuendo, the Blofelds test session,
and/or the PlugIn choice i.e Magnetos.
As Martin had mentioned, we had
already done some collective work in clearing that up, however there were still
individuals who insisted the issues were not related directly to the audio
cards/drivers.
Your results across multiple applications and plugin
variations leaves little doubt that it is directly related to the Audio cards/drivers, and
is a good spring board as we move into Stage II of the DAWbench Project.
I
know the promised L-Factor VSTi test is long overdue, but I hope to have that available
shortly,as well as a beefed up Blofelds DSP template - that has 120 Magneto's
Preloaded.
What has Lynx done right, that the others have missed ?
Thats the enigma that I'd suggest all other manufacturers are hoping to uncover..
:-)
Peace:
V:
|
Phat Riffioso
Joined: 05/08/03
Posts: 498
Loc: London
|
Re: The infamous save and reload 'performance droop'
[Re: TAFKAT]
#388633 - 02/12/06 09:37 PM
|
|
|
Update:
I have been looking more into what is actually causing this performance
anomaly.
The Blofeld’s DAW benchmark suffered really badly from the S&R bug so
my first port of call was to isolate what was causing this. This project uses VST dynamics
plugins, Magnetos, Cubase Channel EQs so these plugins were the basis of my latest
research.
I started a Cubase SX3 fresh project and did some experimenting. I
wanted to see what environments would cause audio dropouts. As with the Blofeld’s test, my
measurement would be based on when dropouts occur and not necessarily when CPU load was
max. After experimenting with various settings, I realised that plugins, were highly
susceptible to not only Sample rate and Buffer Size but Bit depth and whether audio was
passing through it or not.
To obtain more concrete data I set about creating a
simple test project.
I created an audio track with a stereo music file and
saved this as a default project. This would be my monitor channel to hear for any
performance dropouts.
I then created channel presets where all the inserts were
filled with a plugin. The plugins I used were.
VST Dynamics
VST Dynamics
with Channel EQ enabled
Magnetos
Magnetos with Channel EQ enabled
Vintage
Warmer 1.5d
URS Channel Strip
SSL Channel Strip
Waves IR1 v2
Altiverb
5.4.6
Waves Renaissance Comp
I loaded up channels until dropouts would
occur then backed off the plugins until they stopped. This number was noted.
I
saved the project, quit Cubase, reloaded it then took away plugins, if needed, until the
dropouts stopped. This number was noted.
I then duplicated the audio from the
monitor track to the plugin tracks but kept the faders down to avoid output clipping. I
noted down how many plugins were needed, if any, to stop drop outs.
I then took
a different approach to the above procedure. I started a fresh project after restarting
Cubase. I then loaded the default project but then proceeded to load the plugin channels
with the audio already running through them. I noted the maximum number of plugins before
dropouts occurred.
I saved the project, quit Cubase, reloaded it then took away
plugins, if needed, until the dropouts stopped. This number was noted.
The test
was mostly carried around the common 44.1khz quality setting but sample rates of 48khz and
88.2khz were also tested. Bit depths of 16bit 24bit and 32fp were also used. Most of the
testing was based on a 48sample buffer but a control of 256samples was also used.
Spec
Windows SP2
Cubase SX3.1
Fireface 800 2.5.7.1
E6600@ 3.45ghz
2Gb DDR766 spd
P5w DH deluxe motherboard
Onboard TI Firewire
Nvidia
7300gt
All latest drivers as of 1st Dec
Here are the results
(tests were double ran)
There is a real lack of correlation in the results.
It could explain why some people have never experienced the ‘droop’ whilst others get it a
lot. It’s all down the plugins you use and the settings you use them at.
One
observation I made was that Magneto, Vintage warmer and the URS Channel-Strip require more
performance the louder the audio is passing through them. This is worth paying attention
to. In this case louder mixes use more CPU power, but the tonal quality of these plugins
does change with volume so I would say this is acceptable and almost expected. I would be
surprised to see an EQ respond in this way however.
Another observation I made
is that the Cubase multiband dynamics plugin changes tonality depending on my soundcards
buffer size. At low latencies bass decreases and at the largest latency of 1024 the bass
returns to a level which I think is accurate.
This is surprising and somewhat scary
making me think what other plugins out there could respond in this faulty manner, all
those mixes that could change their sound depending on the latency you are using,
There seems to be a slight increase in performance when running in 32fp which may be
worth the increased project sizes.
Taking the above results plus my previous
research and Especially Tafkats research I still believe that they type of soundcard you
are using has a major effect on the performance of your system. Tafkats research shows
that the lynx soundcards don’t suffer from many of these performance problems unlike other
makes of soundcards.
His latest benchmark below really highlights the
performance differences between different systems and the soundcards seem to be a huge
factor.
http://www.aavimt.com.au/downloads/bench2.zip
I would
advise you check this out to see how much your soundcard affects your performance.
More info found here
http://forum.nuendo.com/phpbb2/viewtopic.php?t=8614&start=475
That’s all for now.
Jon
--------------------
Kasha - Picture a beautiful life
|
dmills
Joined: 25/08/06
Posts: 1487
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#388660 - 02/12/06 11:26 PM
|
|
|
I doubt that its sound cards directly, what might be happening is memory fragmentation
which can hurt cache behavior (And possibly the availability of low memory buffers for DMA
and the like) and may cause this sort of thing.
If you are running with a
large amount of ram on a 32 bit box with PAE addressing then the non availability of low
memory buffers directly addressable from the PCI bus is quite likely (Seen it with some
RME hardware, to the point that I couldn't load the drivers).
It could also
be that on reload something is not getting aligned correctly for one of the simd
instruction sets which will always hurt big time for dsp workloads....
Of
course, buggy drivers are always possible.
Does the performance return if the
PC is rebooted?
Regards, Dan.
|
Phat Riffioso
Joined: 05/08/03
Posts: 498
Loc: London
|
Re: The infamous save and reload 'performance droop'
[Re: dmills]
#388675 - 03/12/06 12:03 AM
|
|
|
Quote:
Does the performance
return if the PC is rebooted?
nope once it's gone it's gone. The only way to get it back is to reload every plugin
induvidualy in the project.
Quote:
It could also be that on reload something is not getting aligned
correctly for one of the simd instruction sets which will always hurt big time for dsp
workloads....
I had
some theory it might be something like this but my lack of knowledge of CPU instructions
meant i couldn't really explore this as a variable.
is there a way this can be
tested? or can the processes be reoptimised somehow?
Quote:
If you are running with a large amount of ram on a
32 bit box with PAE addressing then the non availability of low memory buffers directly
addressable from the PCI bus is quite likely (Seen it with some RME hardware, to the point
that I couldn't load the drivers).
Testing on various operating systems are in the pipeline, especially the 64bit
variety.
So are you saying use less ram? 512mb? or is there a Command to load
low mem buffers?
--------------------
Kasha - Picture a beautiful life
|
Peter C
active member
Joined: 08/01/04
Posts: 3038
Loc: London, England
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#388680 - 03/12/06 12:30 AM
|
|
|
This feels to me like an issue cuased in or by the process of allocating the audio card
buffers.
Depending on the relative location of the biffers, and the order in
which they are accessed, you could create a very different memory access patter which
would show up as a varying level of cache misses.
The thing about this
possible explaination is tht it is fundamentallly statistical, and you would expect poor
correlation.
You would also expect the scale and pattern of the performance
variation to change with processor design. It has to be worth while trying this on single
and dual core machines, with c=varying amounts of cache c=vs CPU speed and all possible
architectures - AMD A64/X2, Intel P4/P-D and C2D.
Peter
--------------------
PaQ
|
dmills
Joined: 25/08/06
Posts: 1487
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#388692 - 03/12/06 01:41 AM
|
|
|
Quote PhatRiff:
Quote:
Does the performance
return if the PC is rebooted?
nope once it's gone it's gone. The only way to get it back is to reload every plugin
induvidualy in the project.
Very strange, and this would seem to rule out the soundcard as being an important
part of the problem, as it it were, you would expect the act of rebooting to force the
memory layout back to what it was originally and as the drivers will be reloaded at this
point.....
This says to me that is is something about DAW<>Plugin interaction
that is screwing the pooch on restart after overrun. Maybe he FPU is being left in a funny
mode, maybe the error recovery code path does something, who knows?
Quote:
Quote:
It could also be that on
reload something is not getting aligned correctly for one of the simd instruction sets
which will always hurt big time for dsp workloads....
I had some theory it might be something
like this but my lack of knowledge of CPU instructions meant i couldn't really explore
this as a variable.
is there a way this can be tested? or can the processes be
reoptimised somehow?
This sort of thing can be a nightmare to find, even if you have the source code to the
system, I would hate to do it when there is code from half a dozen parties involved!
Bios author,
Microsoft,
Card drivers (Including video, often doesn't
play nice with others),
DAW authors,
Plugin authors....
ARRRGGH!
Is there some kind of stand alone plugin host you could do the experiment on? That
would potentially eliminate something stupid that the host application is doing?
Really debugging this might in the end come down to running under emulation or even
right down to running with in circuit debugging hardware hung on the bus, kind of not
trivial (Doubly so when you just know some of those plugins have anti softice measures in
place)!
Ilock is not exactly noted for playing nice with debugging tools!
Quote:
Testing on
various operating systems are in the pipeline, especially the 64bit variety.
So
are you saying use less ram? 512mb? or is there a Command to load low mem buffers?
Not really, it is ram in the
first 64 meg that that tends to be critical for PCI DMA buffers, doubly so if the driver
is brain damaged and does not understand scatter/gather DMA.
The reboot thing
is interesting, especially if the same behavior occurs over a cold boot, as this would
IMHO pretty much rule out the low level hardware and card drivers as being contenders.
Sounds to me like memory alignment, denormals or the FPU getting in a funny
mode. All are fixable, but more easily with source code or at least versions of things
without anti cracker features...
Of these, memory alignment would be by first guess,
consider that:
Load plugin
Plugin starts doing its thing.
Load
another plugin.
Plugin starts doing its thing.
.
.
.
Is
going to give a different memory layout (Including any buffers allocated by the plugin as
it starts up), then:
Load plugin
Load PLugin
.
.
.
Start plugins doing their thing....
In particular at small buffer sizes, the
first may give better data locality (important for cache behaviour), then the second, and
I suspect that reloading a session does the second, while loading things up manually does
the first.
To be honest, without getting some fairly scary debugging tools on
this, or a look at the source (Unlikely) it is all guesswork.
Regards, Dan.
|
TAFKAT
member
Joined: 08/01/03
Posts: 130
Loc: Australia
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#388711 - 03/12/06 09:31 AM
|
|
|
Hey Phatriff,
Some great work there Bro.. :-)
This issue has
been quite controversial from the day we first brought it public attention, the exact
mechanics causing the Save/reopen issue has been speculated over and over again, but
inevitably we have not been able to isolate anything concrete over and above the specific
audio card/asio driver implementations.
Blofelds raised two distinct areas of
discussion, one being the huge variances being reported at lower latencies simply running
the session, and also the save/reopen issue. Despite the save re-open issue gaining the
greater notoriety , I found the huge variances with respective audio cards on identical
test systems just as compelling.
In response to dmills,
The
issues being reported were not reserved to any specific CPU architecture, so there is
little chance of it being core execution or instruction related. My feeling is that there
is a specific resource allocation issue that is directly related to the respective audio
hardwares driver implementation.
In some instances, we have tested 3-4 audio
cards on the same system, the constant being the application and the session, the only
variable being introduced was the different audio hardware. The variance in the results
were purely based on the audio hardware being employed.
The new test session
, L-Factor II, is based on VSTi's, and is already displaying similar performance variables
in respect to different audio hardware being used. It does not however suffer from the
save/reopen issue, which gives us some further clues. Where Blofelds is using huge amounts
of PDC , the L-Factor being VSTi based is less reliant of PDC, so that could be giving us
some further insight into what could be causing the resource allocation issue on the
earlier test with certain audio cards.
There are other resource allocation
issues starting to rear their heads in certain areas of the application ,i.e. Nuendo/SX,
specifically GUI, as the newer Core2Duo/Quad systems are simply pushing these applications
into areas where I feel they are exceeding the capabilities of the available
application/code resources..
I give further detail on that on the report
posted at the link above..
Anyhow, all food for thought.., and I am sure
there will be whole lot more discussion before we get a clearer indication on what the
possible causes are..
Peace:
V:
|
LEVEL 1
Joined: 16/06/06
Posts: 12
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#388769 - 03/12/06 01:38 PM
|
|
|
Quote PhatRiff:
I have been
looking into Tafkat's work on the performance droop when reloading projects on certain
audio hardware (well everything except lynx).
He documented how the Nuendo
based blofeld test showed a reduction in the amount of plugins a project could run if it
was saved and reloaded. The reduction gets worse the lower the latencies you work at. The
only way to reduce this effect is to improve the way your audio hardware talks to your
sequencer, in short by installing better drivers.
I have extended this test to
see what other factors can affect this performance droop and if there are any ways to
remedy it bar installing new drivers.
The droop seems to happen regardless of
what plugins are used. Tafkat used the Magneto plug-in in his test but I have found the
waves IR1 suffered from this droop even more severely so I will use this as the base of my
tests.
Test setup
Cpu: Conroe e6600 @ 3.42ghz (should really be
stock speeds)
ddr 760 at 4,4,4,12
Asus P5w DH with 1101 bios
RME
Fireface
TI firewire controller
Windows XP sp2
All latest drivers as of
September 06
Audio at 44100 kHz, 24 bit
Buffer set to 64samples
Multiprocessing turned off
Certain application require you to set a playback
buffer as well so this is set so 2x64 which is what Cubase uses internally.
I
created a test project containing several copies of an audio track. I would then add as
many waves IR1 plugins to the tracks as possible and noted when dropouts would occur. i
saved the project then reloaded the project and noted how many IR1's would need removing
for stability.
Cubase sx3 could take
29 VST instances
29 DX
instances
On reload this would drop to
17 VST
17DX
Ableton
28 VST
Reload 17 VST
SAW demo
17 DX
Reload
17vst
Samplitude 8.0.1
30 DX
Reload 17
Sonar 5 demo
29 DX
Reload 17
So the reload performance of each app is the same.
Except for SAW the initial performance is also similar.
VST plugins are as efficient
as DX plugins.
What’s interesting is that all applications except for SAW show
a few sings of drop out before the maximum plugins was meet. Drop outs would occur as
early as 17 plugins were loaded and they would disappear around 24 then reappear at the
top again. I assume this is why SAW only reaches 17 plugins because playback would stop as
soon as a dropout was sensed even if it was only 1 sample per 1 million. if this
protection was bypassed you could gain performance in the expense of stability.
Cubase was a real tough app to find the performance limit. it would peak at 27 plugins
but if you kept disabling some and adding more I could coax it up to 29.
I also
found out you don't need to reload a song to cause a droop. Changing latency back and
forth and reloading the driver would also cause this. Additionally once a droop had
occurred it could be fully recovered by disabling all the plugins and then reenabling
them.
So what is going on?
This is pure speculation but It seems to
me that the audio driver is not organising the audio threads from the application to the
processor. By reloading the project the threads are thrown out of order which is using up
extra cpu cycles . When the plugins are disabled and reenabled the threads are reordered
more efficiently saving on cpu cycles and improving efficiency.
The question is
why have lynx got it right and all the other manufactures not?
Also some
useful info here
http://www.soundonsound.com/forum/showflat.php?Cat=&Number=346139&page=1&v
iew=collapsed&sb=5&o=7&fpart=1#346139
Ran this test on my machine and I could reload the project with
exactly the same cpu usage?
Cubase SX3
2Ghz Dothan Processor
Intel
855PM Chipset
2Gb 333mhz Corsair DDR RAM
Texas Instruments Firewire Controller
Rme Hammerfall Hdsp Cardbus and Multiface (Buffer set to 12ms)
Edirol UM-550
Windows XP SP 2
|
Phat Riffioso
Joined: 05/08/03
Posts: 498
Loc: London
|
Re: The infamous save and reload 'performance droop'
[Re: LEVEL 1]
#388888 - 03/12/06 08:22 PM
|
|
|
Hi Level 1. Thanks for helping out. That's a good result you have got.
Could
you try some things for me.
I'm wondering if the Edirol um550 is having any
effect on the performance. could you try the test with this unplugged.
Could
you also try a smaller latency. 12ms is 512samples at 44.1khz right? could you try 64 or
1.5ms as higher latencies don't suffer from these problems as much.
What is
your project set at. 44.1khz 24bit?
Thanks Jon
--------------------
Kasha - Picture a beautiful life
|
LEVEL 1
Joined: 16/06/06
Posts: 12
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#388904 - 03/12/06 09:06 PM
|
|
|
Quote PhatRiff:
Hi Level 1.
Thanks for helping out. That's a good result you have got.
Could you try some
things for me.
I'm wondering if the Edirol um550 is having any effect on the
performance. could you try the test with this unplugged.
Could you also try a
smaller latency. 12ms is 512samples at 44.1khz right? could you try 64 or 1.5ms as higher
latencies don't suffer from these problems as much.
What is your project set
at. 44.1khz 24bit?
Thanks Jon
All projects are set at 32bit 44.1khz.
Performed the
test with the buffer set at 1.5ms and also with the um550 unplugged, got the same result.
Although the reason I originally set the buffer at 12ms was because if I set it lower the
sound tends to break up well before max cpu is reached. Also substituted Magneto for IR1
and got the same result, no loss in performance when reloading projects.
Perhaps this problem only affects dual core cpus?
|
Phat Riffioso
Joined: 05/08/03
Posts: 498
Loc: London
|
Re: The infamous save and reload 'performance droop'
[Re: LEVEL 1]
#389680 - 05/12/06 12:52 PM
|
|
|
Thats good news Level 1.
Quote:
Perhaps this problem only affects dual core cpus?
It's a possibility. Although the
architechture of laptops is very different to desktops.
A Single core test on a
desktop and a dual core laptop test with the RME cardbus would be good.
--------------------
Kasha - Picture a beautiful life
|
Koed
Joined: 09/06/06
Posts: 556
Loc: Delft,The Netherlands
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#389702 - 05/12/06 01:28 PM
|
|
|
Has anyone ever brought up the point of memory management?
I've seen several DAW
applications that do not release the memory they used when you close a project.
If
this memory space is then reused for the new project, the memory fragmentation of that
block might become a problem.
One way of testing this could be by using
Cacheman XP between reload to reclaim unused memory space from the DAW application.
|
Phat Riffioso
Joined: 05/08/03
Posts: 498
Loc: London
|
Re: The infamous save and reload 'performance droop'
[Re: Koed]
#389909 - 05/12/06 08:53 PM
|
|
|
Update:
I have now tried my default test project running cubase under Vista 32
pre RTM and the situation is exactly the same. The plugins all respond in the same way. I
also took the liberty of trying RME's latest driver which is one version up from what i
used in the previous tests but still no difference.
Quote:
I've seen several DAW
applications that do not release the memory they used when you close a project.
However, the memory would be cleared
on reboot which unfortunately doesn't fix this problem.
--------------------
Kasha - Picture a beautiful life
|
Peter C
active member
Joined: 08/01/04
Posts: 3038
Loc: London, England
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#389947 - 05/12/06 10:20 PM
|
|
|
Hi,
Interesting discussion. I'd love to be more involved; but I don't have the
requiste setup.
However, could someone please explain to me why
this observed behaviour is so surprising?
Peter
--------------------
PaQ
|
Koed
Joined: 09/06/06
Posts: 556
Loc: Delft,The Netherlands
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#390090 - 06/12/06 10:37 AM
|
|
|
Quote PhatRiff:
However,
the memory would be cleared on reboot which unfortunately doesn't fix this problem.
Errm.. as I read it the problems
only occurs when you load a project and then reload it.
The first load fragments the
memory space allocated to the DAW software.
The reload then tries to fit into the
already fragmented blocks of the first load.
Humor me and try reclaiming
memory between loads 
|
TAFKAT
member
Joined: 08/01/03
Posts: 130
Loc: Australia
|
Re: The infamous save and reload 'performance droop'
[Re: Koed]
#390411 - 06/12/06 10:11 PM
|
|
|
Quote Koed:
Errm.. as I
read it the problems only occurs when you load a project and then reload it.
The
first load fragments the memory space allocated to the DAW software.
The reload then
tries to fit into the already fragmented blocks of the first load.
Humor me and try reclaiming memory between loads
Hmmm,
You seem to be missing the point tho , the memory is cleared on reboot, how can
it be fragmented, also, if it was purely a memory allocation issue at the application
level, then it would be across the board.
It is not happening with all Audio
Cards. Read : Lynx : Whether you reboot or not.. !! So there needs to be another
correlation with the specific Audio Driver implementation..
V:
|
dmills
Joined: 25/08/06
Posts: 1487
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#390468 - 07/12/06 01:03 AM
|
|
|
The reboots that are being used for testing, are we talking cold (as in power right off),
or merely a restart?
I could quite easily see some state surviving a restart
that could potentially cause this weirdness, but I would find it surviving a cold boot to
be indicative of a problem much higher up the stack.
I also query the use of
the very small buffer sizes being discussed, I mean at 64 samples, it doesn't take much to
cause problems and I cannot think of a good reason to run down there except as a
theoretical exercise.
Still, an interesting subject.
Regards, Dan.
|
Phat Riffioso
Joined: 05/08/03
Posts: 498
Loc: London
|
Re: The infamous save and reload 'performance droop'
[Re: dmills]
#393481 - 14/12/06 12:39 PM
|
|
|
Update:
I was doing some experimenting the other day and I found out that
disabling MOST startup items then clearing out the temporary files and cache on EVERY warm
boot I was able to stop the S&R droop on most plugins most of the time. On top of this I
have to have a very strict way of using my operating system. Loading other programs would
increase the likely hood of the droop as would loading up other DAW projects. In fact the
best way to work is to warm boot before every project change. Changing the soundcard
buffer or driver when working on a project would also eventually lead to dropouts.
Basically the environment needs to be kept incredibly controlled.
This I
believe is confirming what people have mentioned earlier in the post about memory
defragmentation. Continually reloading a driver or loading other software will shuffle up
the addresses and the optimal order that your DAW project should be loaded.
So
what is causing the defragmentation?
I tried the following with no success:
Disabling the page file
Increasing the page file to 2Gb
Used Single
Channel Memory (decreased performance but the drop was still there)
Using a
Soundblaster PCI Soundcard (decreased performance but the droop was still there)
Using memory optimising software (snake oil)
Using memory tweaks describes here http://msd2d.com/tips/EXmemory.htm
At this stage the
performance problems tend to be pointing more at the individual software coding. This is
especially the case with the VST dynamics plugin and Waves IR1 These plugins suffer from
it badly. I tried the blofelds test without and VST dynamics plugins and the S&R droop was
very minimal only 5% as opposed to the 50% with the VST dynamics plugins included.
If someone else could check out these plugins on another DAW then I could rule my
system out as the cause of the droop and it could put the blame more on their program
code.
There is still the case why this doesn’t happen at all on LYNX hardware.
Maybe their drivers have the proper code in place to avoid memory defragmentation even on
badly coded plugins like VST dynamics. Possibly something like they allocate a fix part of
memory for the drivers that won’t get interrupted by other bits of software
An additional observation I have made is that the GUI of the plugins fail to load after
a while. First the dials will disappear then the plugin itself will be replaced by a white
box. Also at this point other non Cubase windows will not redraw properly. Dropping the
colour depth to 8bit frees up more graphics memory and cures this problem. This has no
effect on the performance droop though so I would say that graphics hardware is non
relational to this problem.
--------------------
Kasha - Picture a beautiful life
|
Koed
Joined: 09/06/06
Posts: 556
Loc: Delft,The Netherlands
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#393526 - 14/12/06 01:57 PM
|
|
|
Phat, I agree with you that it all points to some less than optimal coding on the software
front.
Because I use my computer for different task, I'll warm boot into a
music partition everytime I need to do some mixing.
Even then I'll always go to the
process explorer and kill off any unwanted processes.
As to the fragmentation ,
I'm starting to think that optimising your page file might heed some results.
Windows
will use the pagefile to swap out memory blocks for programs. If some of these problems
point to memory fragmentation, then optimising the swap abbility of the page file might
reduce the perfomance droop.
Have you tried creating a page file of about 2
times the physical memory on a drive that is not(or rarely) used by the OS or DAW
software?
If the page file is on the same disk as where your audio is streamed from ,
it might have a hard time swopping out all the little fragmented memory blocks and
simultaneously accessing your audio files.
Before you create a new page file on
a drive, make sure you use a good defragger to create enough contigious space on that
drive (if possible at the start of the drive) for the page file to fit in one large block.
|
TAFKAT
member
Joined: 08/01/03
Posts: 130
Loc: Australia
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#393699 - 14/12/06 08:47 PM
|
|
|
Hey Phatriff,
Again, Thank You for all of your time and energy on this..
If it is directly related to only certain plugins , as you have already stated,
it would be across the board in respect to subsystems/audio hardware
Also the
variables reported were not only effecting Save/ReOpen, thats the one that has garnered
the most controversy , but there were also huge variances in simply running the session
respective of the audio card.
O.S Tweaks can easily be ruled out as there
were a number of us that tested multiple cards on the individual test systems, the only
change being made was the Audio Hardware.
No other changes to the systems,
O.S or applications were made.
If the O.S environment needed to be so
clinically controlled, then achieving consistent,reliable,and sustainable DAW performance
would be near impossible, I don't believe that is the case.
Re The GUI
anomalies being experienced: Noted, documented and already reported in an earlier post,
very strange, and basically pointing at a resource allocation issue within Nuendo/SX.
I do not have the exact answer, I still believe that it is possibly related to
the PDC, and the buffering mechanisms involved in handling the huge number of calculations
required, - that may vary depending on respective plugins - and how that correlates with
the specific Audio Driver implementation..
Anyhow,
All Food for
thought..
The search goes on.. :-)
Peace:
V:
|
waxwobbler
member
Joined: 28/01/02
Posts: 217
|
Re: The infamous save and reload 'performance droop'
[Re: Phat Riffioso]
#435670 - 19/03/07 10:09 AM
|
|
|
What is the L-factor II bench ?
--------------------
www.myspace.com/colossaldj www.7161.com/~colossal
|
Martin Walker
Watcher Of The Skies
Joined: 28/02/01
Posts: 12487
Loc: Cornwall, UK
|
Re: The infamous save and reload 'performance droop'
[Re: waxwobbler]
#435786 - 19/03/07 01:09 PM
|
|
|
This is another benchmark designed by Vin (TAFKAT) that concentrates on softsynth rather
than audio track/plugin performance, as you can see below:
Blofelds DSP 40
40 x Stereo Tracks of Audio
40 x 4 band EQs
40 x VST
Dynamics
1 x Multiband Dynamics
40 x Magneto's - 1 per track inactive -
to be turned on during playback - one at a time until session is overloaded
L - FACTOR II
16 x Stereo Tracks of Audio
16 x 4 band
EQs
16 x VST Dynamics
1 x Multiband Dynamics
16 x Midi Tracks assigned
to individual VSTi's.
48 x A1's - Inactive - to be turned on during playback
- one at a time until session is overloaded
If your songs use more softsynths
than audio tracks then the results with L-Factor II will be of more interest. You can read
more about both tests and download them from Vin's dedicated web site: http://dawbench.vze.com
Martin
--------------------
YewTreeMagic
|
Previous
Topics
Next
Threaded
Edit
Reply
Quote
