We cannot control the Pentium and AMD processors the way we do with dedicated DSP chips...
Those conventional processors are running a multithreaded - multiprocess environment in which only slices of time are granted to any particular thread, and when the time slice is up, you are outa here, till the next available timeslice.
In contrast a DSP chip is normally dedicated to doing nothing more than running your DSP algorithm. It also has time limitations based on the same sort of Input/Output buffer sizes and sample rate being used. But it isn't being diverted to updating the screen, writing to the disk, responding to mouse and keyboard, etc.
That's the downside of using commercially available (i.e., cheap by volume sold) computers for what is rightly a dedicated audio processing task....
We all have to take a back seat to spreadsheet users and word processing...
(Scientists have been in this situation for decades... audio buffs are only now finding out how rude the situation can be...)
- DM
10-Band PLParEQ is Here!
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
-
- KVRian
- 1442 posts since 30 May, 2005
OK Markus,xRAVENx wrote:Fritz,
are you telling me there are 50% big cpu load spikes?
edit: I can't put my soundcard to an asio latency high enough to eliminate the dropouts I get with a single 12dB/oct LPF (I get them no matter where the filter frequency is, high and low).
that's something else. How big is your biggest available buffer? What audio card do you use?
For the big drop puts: I have a project here which runs between 60 and 70% at 1024 samples buffers. A few drop outs here and there with PLPareq on the master insert. When I switch to 2048 samples buffer the drop outs are gone and My CPU is around 65%. But in your case it's not good that you can't have a buffer big enough to eliminate the crackles.
All the best, FRitz
In the end will be the word.
Check out some of my music at www.fritzmetal.de
Check out some of my music at www.fritzmetal.de
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
ok...
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
rme fireface, 1024 samples. Test project is at 35% without PLParEQ, at about 40% with PLParEQ and a single 2 pole LPF
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
Markus, try dropping the QL down to 3 or 4. QL 5 is for track bouncing and very very fast computers....
- DM
- DM
-
- KVRian
- 1442 posts since 30 May, 2005
Hm, that's a small biggest buffer! How is it with lower quality settings? Does it work with big buffers when you're bouncing?xRAVENx wrote:rme fireface, 1024 samples. Test project is at 35% without PLParEQ, at about 40% with PLParEQ and a single 2 pole LPF
In the end will be the word.
Check out some of my music at www.fritzmetal.de
Check out some of my music at www.fritzmetal.de
-
- KVRian
- 1442 posts since 30 May, 2005
Oh, David was faster ... 
In the end will be the word.
Check out some of my music at www.fritzmetal.de
Check out some of my music at www.fritzmetal.de
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
I still think when there's 60% cpu headroom available and no cpu spikes visible on any meters, nothing else dropping out before the cpu load is beyond 90%, there should be no dropouts. After all the plugin doesn't even 'use' 10% of the cpu resources available at 1024 samples asio latency, and then it's supposed to have cpu load spikes 6 times that size so fast they don't register on any meter... But then I'm no programmer It's not like I bought the plugin or anything, just thought it'd be a bug or flaw of some sort that could be fixed.
best
Markus
It's not like I bought the plugin or anything, just thought it'd be a bug or flaw of some sort that could be fixed.best
Markus
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
Again, you misunderstand the way the CPU is being used. As FRitz pointed out he has dropouts at 1024 samp ASIO buffers with the CPU running only 60-70%. Upping the buffer size to 2048 samples gets rid of dropouts, and CPU is still in the same range.
There is no programming flaw causing this behavior. It is just simple reality that the computers have limited speed. Some computers are faster than others.
If you have a super-duper highest end processor, then indeed we can use more advanced instructions and possiby speed it up even more for you. But then you don't really need the speedup if you have such a computer... That's just life...
- DM
There is no programming flaw causing this behavior. It is just simple reality that the computers have limited speed. Some computers are faster than others.
If you have a super-duper highest end processor, then indeed we can use more advanced instructions and possiby speed it up even more for you. But then you don't really need the speedup if you have such a computer... That's just life...
- DM
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
I consider dual opterons pretty fast, and 60% cpu overhead available while PLParEQ displays to be using less than 10% plenty of room available, according to the cpu meters that cpu overhead isn't being used.
Also I was quoting Fritz on the cpu spikes that aren't visible anywhere. As it is I can't use a single filter without dropouts, I find dropouts rather disturbing when mastering. And I sure won't be bouncing a project, wait a few minutes, then listen to how the EQ sounds and how I should tweak it.
And quite frankly, spreadsheets this or graphics that, there are lots of cpu resources left unused, and there are dropouts.. that's the part I don't understand. But then a grand saved is a grand earned.
best
Markus
edit: why not release your plugin also for the powercore platform? Plenty DSP power there, purely for audio processing.
Also I was quoting Fritz on the cpu spikes that aren't visible anywhere. As it is I can't use a single filter without dropouts, I find dropouts rather disturbing when mastering. And I sure won't be bouncing a project, wait a few minutes, then listen to how the EQ sounds and how I should tweak it.
And quite frankly, spreadsheets this or graphics that, there are lots of cpu resources left unused, and there are dropouts.. that's the part I don't understand. But then a grand saved is a grand earned.
best
Markus
edit: why not release your plugin also for the powercore platform? Plenty DSP power there, purely for audio processing.
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
I believe that PowerCore is DSP 56K. Those have neither sufficient speed, nor sufficient numeric precision. We could do a sawn-off version for them...
And, don't go away angry... I wish there were something I could do for your dual Opterons. But at the moment, there doesn't seem to be.
It also depends on how you optimized your overall system for DAW work. How you set up the Win/XP for multiple processes, how many threads are active in the background, and so on.
- DM
And, don't go away angry... I wish there were something I could do for your dual Opterons. But at the moment, there doesn't seem to be.
It also depends on how you optimized your overall system for DAW work. How you set up the Win/XP for multiple processes, how many threads are active in the background, and so on.
- DM
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
David,
I'm not angry, didn't mean to make the impression either. I think the EQ sounds great, and I wish I could use it fully without dropouts, because they're highly distracting when I try to concentrate on the sound of the program material.
The DAW is well optimized, at 256 samples latency I can load the two cpus to ~96% without a single dropout. Nothing is active in the background, it's a dedicated DAW.
Markus
I'm not angry, didn't mean to make the impression either. I think the EQ sounds great, and I wish I could use it fully without dropouts, because they're highly distracting when I try to concentrate on the sound of the program material.
The DAW is well optimized, at 256 samples latency I can load the two cpus to ~96% without a single dropout. Nothing is active in the background, it's a dedicated DAW.
Markus
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
Sounds like a very nice system!
But again, CPU load is only weakly connected to whether or not dropouts occur. True enough if the CPU load goes through the roof you will almost certainly have dropouts, but the converse is not necessarily true.
- DM
But again, CPU load is only weakly connected to whether or not dropouts occur. True enough if the CPU load goes through the roof you will almost certainly have dropouts, but the converse is not necessarily true.
- DM
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
Markus,
I don't know that much about the AMD line of processors... but if your processor is one of the newest high-powered versions from AMD, I may be able to recompile with advance compiler options to get more speed. No guarantees that it won't crash your system, but it might be worth a try... Drop me note...
- DM
I don't know that much about the AMD line of processors... but if your processor is one of the newest high-powered versions from AMD, I may be able to recompile with advance compiler options to get more speed. No guarantees that it won't crash your system, but it might be worth a try... Drop me note...
- DM
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
You're right there of course, at 64 samples latency I get dropouts at about 80% cpu load.
It's just that dropouts don't occur before well beyond 90% cpu load, except for PLParEQ, which gives me dropouts anywhere, even at 1024 samples latency (loads of dropouts with PL enabled, few dropouts without, even when the overall load is under 50% at 1024 samples asio latency).
So far none of the plugins I use have specific dropout thresholds, I get dropouts when I get above e.g. 96% at 256ms asio latency, or at 1024 samples when there are cpu load overs. I never encountered before that a single plugin causes dropouts while other plugins don't.. and considering the cpu overhead available to be used makes it even less understandable.
I can only observe plugin behavior really, and compare it to others. I'd understand if there were cpu spikes that just aren't visible, but that doesn't seem overly plausible to my non programmer mind, that there are spikes that cause half a dozen times the cpu load the plugin displays on the meters
It's just that dropouts don't occur before well beyond 90% cpu load, except for PLParEQ, which gives me dropouts anywhere, even at 1024 samples latency (loads of dropouts with PL enabled, few dropouts without, even when the overall load is under 50% at 1024 samples asio latency).
So far none of the plugins I use have specific dropout thresholds, I get dropouts when I get above e.g. 96% at 256ms asio latency, or at 1024 samples when there are cpu load overs. I never encountered before that a single plugin causes dropouts while other plugins don't.. and considering the cpu overhead available to be used makes it even less understandable.
I can only observe plugin behavior really, and compare it to others. I'd understand if there were cpu spikes that just aren't visible, but that doesn't seem overly plausible to my non programmer mind, that there are spikes that cause half a dozen times the cpu load the plugin displays on the meters