KVR Audio

munchkin · Post by **munchkin** » Thu Oct 05, 2006 8:07 pm

After a bit more testing my initial excitment that it loaded at all in ACID has waned. 4 instances of GPU Delay cause my cpu to hit 20%. I've even tried adjusting my video card to various performance settings but it doesn't make any difference.

In contrast 15 track optimised SONY delays in ACID use 5% of cpu.

fake · Post by **fake** » Thu Oct 05, 2006 8:17 pm

Same here with the loud buzz but I think it's the card.

An asus radeon 9200se 128mb.

Pity, I would love to have tried it out.

fake

Nils Schneider · Post by **Nils Schneider** » Thu Oct 05, 2006 8:17 pm

What block size do you use?

The performance boost will not be noticable with just a delay, as mentioned before, this is just a proof-of-concept, just to check if it's working at all.

Something might be wrong, as other don't have this problem....

jens · Post by **jens** » Thu Oct 05, 2006 8:19 pm

Nils Schneider wrote:Which drivers and which version do you use? An update to the latest forceware driver may help.

91.31

I'll check if there's a never version and if so will udate it...

munchkin · Post by **munchkin** » Thu Oct 05, 2006 8:23 pm

Testing with Voxengo Analogueflux Delay I'm getting same cpu hit as GPU delay. I think the GPU Delay is using the cpu instead of the gpu for some reason.

ddummer · Post by **ddummer** » Thu Oct 05, 2006 8:46 pm

Well it IS a native plugin sending and reciving data from
the graphic card so the CPU hit would be as normal only
that the communication is there.... if I understand it right...

...a test to see that you can expand the VST code into the
Graphic board in realtime...

//Daniel

munchkin · Post by **munchkin** » Thu Oct 05, 2006 9:10 pm

But some people are getting virtually no cpu hit even when using a lot of delays. If this plugin is going to use the gpu instead of the cpu then it needs to use less cpu not the same as other native delays.

Could there be a difference between ATi and GForce drivers?

Nils Schneider · Post by **Nils Schneider** » Thu Oct 05, 2006 9:10 pm

To clear this up:

ddummer is right, I have to convert the audio data into graphic data, send them to the GPU, and vice versa. And this process consumes time on the CPU that isn't avoidable. But this time ALWAYS remains the same, regardsless of how complicated the effect on the GPU might be.

If this whole process is "only" eating as much as a delay, it's already very good, because a delay costs nearly nothing because the algorithm is one of the cheapest you can have.

The GPU *Delay*, the effect that you can hear, this one is computed on the GPU, not the cpu! I didn't write a delay algorithm on the cpu at all so you can be sure it's the GPU you're listening to. It's not possible that the CPU calculates the delay. This can be compared to playing CDs on a vinyl player. That WONT WORK

btw: I've found the crash bug when terminating the VST host, will be fixed in the next release, plus some other things.

munchkin · Post by **munchkin** » Thu Oct 05, 2006 9:17 pm

Ok I get it now. So if you make a really complex modular synth I can use 128 voices in unison mode and it'll only use the same amount of cpu as the delay?

Will it be possible to build a convo verb using the gpu and would latency be a problem? I'm asking this because I think UA and TC Electronic haven't made one for their DSP cards because of problems with latency.

Nils Schneider · Post by **Nils Schneider** » Thu Oct 05, 2006 9:24 pm

Define "problem", latency can easily be compensated in modern hosts so this should'nt be an issue.

BTW: Also the delay has a latency equal to the processing blocksize (you can see it if you use Cubase SX and take a look at the plugin information window).

This is because data must be transferred to the gpu, processed, and then send back. Because you would have no advantage if the cpu had to "wait" for the whole process, there is always a latency of one frame.

VitaminD · Post by **VitaminD** » Thu Oct 05, 2006 9:43 pm

btw my buffer is 2048.. I refuse to change it too

uvacom · Post by **uvacom** » Thu Oct 05, 2006 9:54 pm

At a buffer size of 512, I ran 7 instances in cubase without any trouble, actually without any noticeable CPU hit at all. I would imagine I could run 20 or 30 easily. That's with a 128mb radeon 9800 Pro.

I did come across one arror - if this plugin is placed on a send in cubase, and the send is muted, the return stream is not muted. This works fine with other plugins.

Anyway, very cool and *very* exciting technology. Convolution reverb would be cool, but with this kind of delay stream processing power, one could code a serious algorithmic reverb, no?

Nils Schneider · Post by **Nils Schneider** » Thu Oct 05, 2006 9:58 pm

@uvacom thanks for testing, could you check if cou get a warning in sgpu.log in the installation directory? I was too lazy to implement the process() function yet (just calling processReplacing)

olzzon · Post by **olzzon** » Thu Oct 05, 2006 10:10 pm

munchkin wrote: Will it be possible to build a convo verb using the gpu and would latency be a problem? I'm asking this because I think UA and TC Electronic haven't made one for their DSP cards because of problems with latency.

I think it has more to do with lack of RAM on their cards
And a GPU don't have that problem, because of the graphiccard RAM

Nils Schneider · Post by **Nils Schneider** » Fri Oct 06, 2006 1:18 am

Thanks for all your help. NEW VERSION UPLOADED

http://www.nilsschneider.de/temp/GPUDelay.exe

Changes:

- Distorted sound on several buffer sizes fixed
- Overall better error handling and more log file output
- Crash on shutdown fixed (could also happen while still inside the host)

Those who had problems with crackling sound could give it another try now, It should sound okay now.

GPU Delay - A delay plugin running on a graphics card