10-Band PLParEQ is Here!
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
David,
any chance for a version that works fine with dual amd cpus (i.e. dropout issue)?
Markus
any chance for a version that works fine with dual amd cpus (i.e. dropout issue)?
Markus
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
Hello Everyone...
A lot of folks are complaining of dropouts at high Quality levels. I get them too. The highest quality levels put the hardest strain on your computers, and these were meant primarily for track bouncing to stereo print with highest possible quality.
But for realtime tracking and mixing (at least in rehearsal mode) you ought to be doing most of your work at lower quality settings like 3 or 4, or even lower.
The higher up you go, the deeper you can reach into the bass region with something like a steep high-pass filter.
Rule of thumb... you need a blocksize roughly 3 times (or more) longer than the period of the lowest frequency you are trying to effect with fidelity.
So at SR 44.1 kHz, a 50 Hz tone has a period of 20 ms = 882 samples. So your buffer size for good fidelity needs to be at least 3 times larger, or 2646 samples. Looking in the PDF brochure, the 3-band has a buffer size of 2048 at QL 3, or 4096 at QL 4. I would go with QL 4, but 3 would probably do okay too...
Then after rehearsing the fader movements and effects changes and when you are ready to print the track, push the QL all the way up to get the highest quality print.
Cheers,
- DM
A lot of folks are complaining of dropouts at high Quality levels. I get them too. The highest quality levels put the hardest strain on your computers, and these were meant primarily for track bouncing to stereo print with highest possible quality.
But for realtime tracking and mixing (at least in rehearsal mode) you ought to be doing most of your work at lower quality settings like 3 or 4, or even lower.
The higher up you go, the deeper you can reach into the bass region with something like a steep high-pass filter.
Rule of thumb... you need a blocksize roughly 3 times (or more) longer than the period of the lowest frequency you are trying to effect with fidelity.
So at SR 44.1 kHz, a 50 Hz tone has a period of 20 ms = 882 samples. So your buffer size for good fidelity needs to be at least 3 times larger, or 2646 samples. Looking in the PDF brochure, the 3-band has a buffer size of 2048 at QL 3, or 4096 at QL 4. I would go with QL 4, but 3 would probably do okay too...
Then after rehearsing the fader movements and effects changes and when you are ready to print the track, push the QL all the way up to get the highest quality print.
Cheers,
- DM
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
David,
when the CPU meter sits at 65% with PLParEQ operating on a project (roughly 10% of that is PLParEQ, a single 12dB/oct LPF) and there are lots of dropouts, is that supposed to happen, when at the used latency I can strain the CPU to over 90% without a single dropout otherwise? I get PLParEQ dropouts as soon as the total cpu load is above 50%.
Please confirm that this is the supposed behavior of your plugin, then I'll stop reporting that
best
Markus
when the CPU meter sits at 65% with PLParEQ operating on a project (roughly 10% of that is PLParEQ, a single 12dB/oct LPF) and there are lots of dropouts, is that supposed to happen, when at the used latency I can strain the CPU to over 90% without a single dropout otherwise? I get PLParEQ dropouts as soon as the total cpu load is above 50%.
Please confirm that this is the supposed behavior of your plugin, then I'll stop reporting that
best
Markus
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
Hi Markus,
What Quality level are you using?
What Quality level are you using?
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
David,
5. I wonder if that's supposed to matter though? What else except too high cpu strain causes dropouts?
best
Markus
5. I wonder if that's supposed to matter though? What else except too high cpu strain causes dropouts?
best
Markus
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
... you see, it isn't the CPU load that is of paramount importance... it is the ability to compute buku filter operations on large buffers in the requisite amount of time between the VST feeding buffer loads of new input samples...
The higher the QL, the more work the filters have to do in the same amount of time.
That's why pushing the ASIO buffer size higher may help remove clicks and pops...
The higher the QL, the more work the filters have to do in the same amount of time.
That's why pushing the ASIO buffer size higher may help remove clicks and pops...
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
See, I could have a really souped up processor that just loafs along at 96 kHz SR and QL 6, and still get dropouts, because it can't compute the needed number of output samples in the time between successive input blocks. That's what causes dropouts...
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
What do you mean, David? Are you saying you are artifically forcing dropouts to happen? Why not just let the user decide by the latency they chose how much cpu horsepower they want to get wasted?
I get it when dropouts happen because cpu is running out, but having them happen for no reason I don't quite understand
I mean you don't really achieve a resource improvement by forcing the user to use higher latencies, even though they have plenty cpu power left.
Just don't quite get how the tradeoff dropouts but less cpu use is good for anyone
best
Markus
I get it when dropouts happen because cpu is running out, but having them happen for no reason I don't quite understand
I mean you don't really achieve a resource improvement by forcing the user to use higher latencies, even though they have plenty cpu power left.
Just don't quite get how the tradeoff dropouts but less cpu use is good for anyone
best
Markus
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
Huh? I cannot force dropouts to occur... The VST host sends me buffer loads of samples, the size of which appears to depend on the ASIO buffer size.
So I have the time it takes to fill one of these buffers with live samples, as the period of time to compute all of my blocksize samples inside the DSP core.
If the buffer size is only 128 samples, that leaves very little time, especially at QL 5 where I have to work on 8192 stereo samples. I would have to have a very fast processor to pull that one off.
Upping the ASIO buffer size to something like 1024 samples gives me 8 times more room to get the same workload finished.
And this is why high QL settings for track-bouncing work well. There is no time limit on processing for track bounce.
But there is a definite limit on realtime processing. The higher the sample rate, and the smaller the blocksize used by ASIO buffers, the more I have to accomplish in less time. Simple as that.
- DM
So I have the time it takes to fill one of these buffers with live samples, as the period of time to compute all of my blocksize samples inside the DSP core.
If the buffer size is only 128 samples, that leaves very little time, especially at QL 5 where I have to work on 8192 stereo samples. I would have to have a very fast processor to pull that one off.
Upping the ASIO buffer size to something like 1024 samples gives me 8 times more room to get the same workload finished.
And this is why high QL settings for track-bouncing work well. There is no time limit on processing for track bounce.
But there is a definite limit on realtime processing. The higher the sample rate, and the smaller the blocksize used by ASIO buffers, the more I have to accomplish in less time. Simple as that.
- DM
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
Assuming PLParEQ reports it's required latency to the host, it could just use whatever cpu it needs... no? DSP card based effects do the same, they report the latency they need to get all the audio data, then everything else just costs DSP resources.
I'm just wondering why it's even possible to get the EQ to dropout with loads and loads of cpu overhead available.
best
Markus
I'm just wondering why it's even possible to get the EQ to dropout with loads and loads of cpu overhead available.
best
Markus
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2005 from Tucson, AZ, USA
No, you misunderstand latency reporting.
The plugins report their latency settings -- how long they delay the input -- so that the host knows how to align its output with other tracks to keep everything in sync.
Latency may or may not have anything to do with how much processing is going on. And in any event, you cannot take more time than it takes to fill one ASIO buffer or else you will cause dropouts. But that is not the same thing as latency.
- DM
The plugins report their latency settings -- how long they delay the input -- so that the host knows how to align its output with other tracks to keep everything in sync.
Latency may or may not have anything to do with how much processing is going on. And in any event, you cannot take more time than it takes to fill one ASIO buffer or else you will cause dropouts. But that is not the same thing as latency.
- DM
-
- KVRian
- 1442 posts since 30 May, 2005
Hey Markus,xRAVENx wrote: I'm just wondering why it's even possible to get the EQ to dropout with loads and loads of cpu overhead available.
best
Markus
I would say it this way: When you've got a dropout then there is NOT enough CPU power available for THAT particular short moment of time. The average before or after that isn't important for that.
Best wishes, 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
Why doesn't the plugin automatically report the latency it needs for any frequency (i.e. the highest one) in order to get enough audio data?
And if it's not a matter of getting enough audio data to process (e.g. lookahead of some sort).. it's more cpu it eats (or should eat) depending on the asio latency, right?. As for how much cpu is needed to process it, just let the user determine that, no? Right now I got a load of cpu overhead but PLParEQ doesn't use it, it just crackles.
Markus
And if it's not a matter of getting enough audio data to process (e.g. lookahead of some sort).. it's more cpu it eats (or should eat) depending on the asio latency, right?. As for how much cpu is needed to process it, just let the user determine that, no? Right now I got a load of cpu overhead but PLParEQ doesn't use it, it just crackles.
Markus
-
- KVRian
- 1202 posts since 8 May, 2003 from Munich
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).
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).