bladerunner.
ConquistadorHi Frits,
This has been an off and on kind of problem for over year at least. On Windows XP and now Vista.
It does not seem to matter what combination of plugs I use , buffer settings e.t.c it all seems to boil down to Podium. The same set of plugs in another host will result in a steady CPU reading with perhaps 5% either way.
In Podium I can be playing back a track and zap, it just spikes by up to 30%.
I am running extremely lean Windows installations. The whole process seems to be random in nature.
It is as if Podiums engine is far more sensitive to the slightest activity elsewhere on Windows.
The Problem is with no Virus scanner, Firewall or anything else I can think of active to disturb it, spikes like that should not be happening.
While there are of course different reasons for CPU sikes typing in “spike” in the forum search field brings up a very long list of similar issues.Not all the same cause but very similar problems.
Thoughts?
ZynewaveThis could be due to the sensitivity of the Podium CPU indicator. Other hosts may measure the CPU usage differently, but could still suffer from the spikes if you are close to overloading the CPU. To be sure it is a problem related to Podium, you need to look at the CPU usage in the Windows task manager, and compare it with other hosts.
Conquistador@Zynewave wrote:
This could be due to the sensitivity of the Podium CPU indicator. Other hosts may measure the CPU usage differently, but could still suffer from the spikes if you are close to overloading the CPU. To be sure it is a problem related to Podium, you need to look at the CPU usage in the Windows task manager, and compare it with other hosts.
Could be the problem. The Podium CPU meter definitely responds in a more sensitive way…too sensitive IMO. Unless there is another problem somewhere.
In any case I will have a look at Windows Task manager as suggested and compare with other hosts.
Should be interesting. I really want to get this problem out of the way.
ConquistadorOk done some tests and comparisons.
Podium seems to be running perfectly OK as far as the Windows task manager is concerned…only 5 % roughly CPU changes at any given time.
No 20 -30 % spikes, so as you suspected it may very well be Podiums CPU meter that is perhaps too sensitive.
But within Podium random spikes continued sometimes once during an 80 bar track at times more than once. While all this was going on the Windows task manager showed a steady CPU load with only a 5% change roughly either way.
One of course does not want a CPU reading that is not responsive enough but it is almost as if Podiums CPU meter’s attack setting is too high (for want of a better word to describe it) so it’s picking up things it need not.
Compared to Sonar, Live and Project 5 they only have about a 5% – 7% movement either way roughly.
Podium can be running with about a similar CPU variation in load for half a track then wham…30% increase. In some cases for a split second even higher. It just does not happen like that with other hosts I have tried.
It must be Podiums CPU reading because windows CPU reading AFAICT from my tests is not erratic and does not have crazy 30% spikes or higher out of nowhere.
It seems a strange problem to have in such a reliable host but perhaps a slight reduction in the attack of the CPU sensitivity setting would do the job and bring Podiums CPU meter a bit more in line with others I have tried.
KlempererOnly thing I noticed as a start-now-Podium user now is that compared to EnergyXT or Tracktion the *loading* of a VSTi gives a short turn into the red and a high spike, and again only in Podium itself. But this is so obviously changing after a few seconds and does no harm, so any demo-user won’t bother with this.
ZynewaveThe Windows task manager possibly measures over longer periods, and so short spikes are evened out.
I consider the Podium CPU indicator both as a measure for general CPU load, as well as a warning indicator of how close you are to overloading. I think it is important to show the spikes, because if they happen to go to 100%, you will get audio dropouts. Other hosts may have less sensitive CPU indicators, but you then risk getting unexpected audio dropouts at a lower CPU percentage. I’ve seen posts on kvr where people state that for some hosts they can only reliably utilize up to ~60% before they start getting audio dropouts.
Conquistador@Klemperer wrote:
But this is so obviously changing after a few seconds and does no harm, so any demo-user won’t bother with this.
I think it will not of course bother everyone. But I do think there are some people like me and many others who have posted CPU issues on this forum that will be concerned. Having said that I was referring to playback issues, not the initial start up CPU burst.
So perhaps we are talking about the same thing but in a different scenario. 😉
In any case I think I know what the cause and maybe solution is now unless Frits tells me I don’t know what I am talking about 🙂
The Windows task manager possibly measures over longer periods, and so short spikes are evened out.
Maybe. I have no idea. I wish I knew. 🙄
I consider the Podium CPU indicator both as a measure for general CPU load, as well as a warning indicator of how close you are to overloading. I think it is important to show the spikes, because if they happen to go to 100%, you will get audio dropouts.
I think I know what the problem is. If…and I repeat if 😉 Podium’s CPU meter is not just reporting what the CPU performance of Podium is FX, VSTi load for instance..if it is also showing underruns as they happen, then that I think is why there are spikes.
Perhaps they are not spikes (which sounds like a bug) but underrun readings. I think the problem here is that compared to other hosts (comparison is unavoidable) it does look problematic to see strange spikes in a CPU meter. Others are steady (likely not reporting underrun activity) and as a result appear stable or less erratic compared to Podium’s CPU meter.
Anyway, cut a long story short…I read Technophobias thread here
http://www.zynewave.com/forum/viewtopic.php?t=819&highlight=spikes
From what I read there, it is almost certainly what the problem is. It probably is not the sensitivity at all, but the fact that underrun activity readings (correct readings most likely) are shown on the same CPU meter that reports, for want of a better word, standard host CPU load. FX and VSTi’s CPU load for instance.
So I come out of Live 6…nice steady CPU…load up Podium after 30 bars wham…30% spike. Huh?
It must be underunns. Correct?
Also I dont seem to get any drop outs audio wise. Perhaps this muddys the waters a bit. The spikes I get are at very low CPU usage 15%? So the spikes are surely not telling me about an impending overload, not at 15%! So what is going on at such a low CPU setting?
Can one or should one get underunns even at low CPU usage?
Other hosts may have less sensitive CPU indicators, but you then risk getting unexpected audio dropouts at a lower CPU percentage.I’ve seen posts on kvr where people state that for some hosts they can only reliably utilize up to ~60% before they start getting audio dropouts.
I think this may be the case for every host. Including Podium. I think once you get close to 70% one is probably pushing it. But…I have actually gone further in Podium but of course one spike at that kind of load and a red flash will likely follow.
Do underruns always lead to drop outs in audio? If so why do I not get dropouts when the CPU spikes?
Does Podium provide a reading for the ASIO sample point position and underunns seprately as they happen or are they the same thing? Problems with the sample point positions causing underruns which Podium reports to the UI (CPU meter)?
FL studio…
This has a very interesting option that lets you see them as they happen. Just like Podium but…in numerical form not as a CPU reading. As you adjust this setting in FL the underruns reduce until a balance is acheived.
More details here…
http://www.flstudio.com/help/html/glossary_underrun.htm
Please try out FL’s demo and play any demo track and go to this setting in FL to see the underrun numerical read out change as you adjuts the buffer settings. Bottom left of second image
http://www.zynewave.com/forum/posting.php?mode=quote&p=8928
Is this what is being shown on Podiums CPU meter?
Many questions, sorry 🙂 but I am trying to understand what is going on here as it does not look like a bug or such but perhaps a different way of displaying that info. An idea…
…a small meter next to Mix/File and a small tool tip that appears explaining what it does would be better.
That would mean the Mix CPU meter would better mirror other hosts causing a lot less confusion. You would also not need in any way to alter the current reporting process in Podium.
If Technophobias thread is anything to go by that information (underrun activity in full view of a user) shows how problematic some ASIO drivers are. So well done there. 8)
Raising my latency a little produced a steady CPU setting 5% either way 20ms. OK for mixing but not playing.
If I was to play a piece I guess I could bounce it down to audio early but…even playback at 10ms here produced spikes with Stylus RMX.
Can you consider a small meter like the I/O meter that maybe has U written on it for underunns?
Underruns do not appear to cause drop outs here my CPU usage is too low perhpas that is why, so If I can see that the Mix CPU is steady at low latencies, but the (for example) U meter is spiking I know it will not affect playback but I just need to keep an eye on it.
But 30%+ spikes on the Mix meter leave me guessing as to what is the cause. A buggy FX, VSTi? I could hunting down the problem for a long time. Raising my latency setting may even mask such a problem!
A separate U meter would make it 100% clear at a glance, what exactly is going on IMO.
Thoughts?
ConquistadorDuplicate post.
Technophobia@ Conquistador & Frits
I still have the CPU spikes (100%) on my system, but, and I must stress this, it’s down to my EMU 1820m drivers. I reported this to EMU and guess what…They said they would look into it – that was nearly 18 months ago.
I am eventually going over to Firewire with probably TC Electronic so that I can be rid of this buggy card system from EMU.
I don’t know what audio interface you are using Conquistador, perhaps that is the problem, though of a lesser problem than mine. In all fairness to my 1820m, there has not been any dropouts so far but, I don’t really push it that much either.
Beware the EMU….. 👿
H-man@Conquistador wrote:
Podium seems to be running perfectly OK as far as the Windows task manager is concerned…only 5 % roughly CPU changes at any given time.
No 20 -30 % spikes, so as you suspected it may very well be Podiums CPU meter that is perhaps too sensitive.
But within Podium random spikes continued sometimes once during an 80 bar track at times more than once. While all this was going on the Windows task manager showed a steady CPU load with only a 5% change roughly either way.
Conquistador, I have done some testing on my sytem recently and have observed that Task Manager (when open) causes these (20 – 30%) spikes.
Instead I used System Informaiton for Windows (SIW) http://www.gtopala.com/ for which the spikes did not appear.
Everyone’s PC is different however I can assert that on my system, I would certainly see these spikes (in Poduim) when Task Manager was open, and they would dissapear when Task Manager was closed.
(Typical load for tests was 60 -70%, Anti-virus off)
Conquistador@H-man wrote:
Conquistador, I have done some testing on my sytem recently and have observed that Task Manager (when open) causes these (20 – 30%) spikes.
Hi H -Man,
Yes you are correct but I already knew about the Task manager being open and Podium spiking but…that was just another cause for the spikes not the reason I started this thread.
I would not work with the Task manager open anyway.
I only mentioned the Task manager to give Frits a comparison with Podiums CPU meter. The spikes I was experiencing were with the Task manager *not open or even minimised*.
No Virus scanner or Firewall active either. It turned out to be a graphics setting I had to play around with. Adjusting for perfomance seemed to solve the problem. Strangely pushing all the settings back up for the highest quality seemed to keep things normal. I may have just needed to re load some graphic settings. In any case it worked. 🙂
Instead I used System Informaiton for Windows (SIW) http://www.gtopala.com/ for which the spikes did not appear.
Ok…definitely worth a look thanks.
Everyone’s PC is different however I can assert that on my system, I would certainly see these spikes (in Poduim) when Task Manager was open, and they would dissapear when Task Manager was closed.
Agreed, see above. 🙂
H-manOkay, cool. Just trying to help 😀
As you will know I haven’t been working with Podium for all that long and I have chosen to start new compositions rather than migrate old ones (from other DAW).
Needless to say, sooner or later (probably sooner) you get to the point where the load on the PC is getting high and you want to do everything possible to keep it all ‘dynamic’, squeeze in that extra reverb and not have to boucne to audio.
We all try and run ‘quiet systems’ and I noticed that you had some good advice regarding Nebula3 performance (http://www.zynewave.com/forum/viewtopic.php?t=1399&highlight=nebula3) for both Podium and Nebula3.
Needless to say I am very interested in this type of info for Podium (XP and Vista) and although there are plenty of pearls of wisdom in this forum, It might be nice to aggregate them somehow?
Klemperer@Conquistador wrote:
@Klemperer wrote:
But this is so obviously changing after a few seconds and does no harm, so any demo-user won’t bother with this.
I think it will not of course bother everyone. But I do think there are some people like me and many others who have posted CPU issues on this forum that will be concerned. Having said that I was referring to playback issues, not the initial start up CPU burst.
So perhaps we are talking about the same thing but in a different scenario. 😉
You’re right. I think we didn’t even talked about the same thing, so I could have made that more clear. I just talked with 3-4 other possible Podium-users of the future while reading here who were concerned about this while comparing Podium with some alternatives. So your post was right for long-time users, and mine was right as a little clarification for newer users with no experience at all with the program 😉 . Things solved now, so all’s great 😀
bladerunnerrather than start a new thread i thought i would post some cpu observations here as it is relevant to this thread. i have always had the cpu spiking issue discussed here. i am using asio4all version 2.9 on a vista home premium equipped pc with a core 2 duo E6550 processor and 2 gigs of ram. to try to find the cause in the past i have tried disabling all sorts of devices, disabling all but the most essential background processes, startup processes etc. but all to no avail. what i have found today is that the spiking seems to be directly related to the asio buffer size. i don’t know if this is something generally known already.
i made a simple project with 6 instances of the zynewave nucleum synth and one zynewave reverb as a send. this uses around 25% of the cpu. at a buffer size of 320 samples i am getting regular spikes (every 20 seconds or so) some of which will hit the 70% mark now and again. increasing the buffer size lowers the size of these spikes until i get to 1024 samples at which point the spikes almost disappear completely. obviously i am pleased that i have found a solution as at one point it was stopping me from starting a new project in podium. a sample size of 1024 gives me a latency of 27 ms which is not great for playing a midi keyboard but manageable. cpu usage in other hosts that i use don’t seem to be affected by the buffer size.
has anyone else found this direct relationship between the spikes and the buffer size?
ZynewaveSome plugins may occasionally perform some heavy computation which is not part of the normal processing (if you e.g. automate parameters which require further recalculations in the DSP algorithm). If this heavy computation has a duration of e.g. 3 milliseconds, then this will cause a spike at ~50% if the ASIO buffer size is 6 milliseconds. The same computation will only cause a spike at ~10% if the buffer size is 30 milliseconds. Etc.