KVR Audio

zeep · Post by **zeep** » Fri Oct 06, 2006 11:02 am

Very interesting development. A question, i see many mentions of a dll that has to be installed manually, the d3dx_* one, why is this necessary?

I have a 9800pro 128mb videocard in my 1st daw, will i need to install a dll too?

Nils Schneider · Post by **Nils Schneider** » Fri Oct 06, 2006 11:03 am

duncanparsons wrote: FL does strange things to enable VST automation to be sample accurate, amongst other things. sampleframes=1 is not uncommon with it, so you will need to keep your own buffer for such situations

grrrrrr.......

Just downloading the demo to check this.....

zeep wrote: A question, i see many mentions of a dll that has to be installed manually, the d3dx_* one, why is this necessary?

I have a 9800pro 128mb videocard in my 1st daw, will i need to install a dll too?

I'm not sure why this happens, I used the february SDK for directX, but I'm just downloading the newest one so this should no longer be necessary in the future. Unfortunately Microsoft doesn't allow to ship this dll....

duncanparsons · Post by **duncanparsons** » Fri Oct 06, 2006 11:19 am

tony tony chopper is the guy to speak to about FL. His real name is Gol.. you'll find him in the DSP plugin forum

DSP

jens · Post by **jens** » Fri Oct 06, 2006 12:21 pm

jens wrote:
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 update it...

updating Forceware didn't help...

jens · Post by **jens** » Fri Oct 06, 2006 12:21 pm

duncanparsons wrote:His real name is Gol..

yeah, sure...

Aleksey Vaneev · Post by **Aleksey Vaneev** » Fri Oct 06, 2006 2:41 pm

This could be done by using OpenGL (which is probably a bit wider available).

This thread proves me right of not releasing my experiments with convolution on GFX card.

It simply would not work on many computers/gfx card configurations thus causing frustration.

I now think that a special 'gpuhost' program should be created that should stay open when GPU plug-in is needed to be loaded. This will remove all small and big API calls associated with graphics cards, OpenGL or DirectX out of audio host environment. These things may slow-down things a lot there.

The 'gpuhost' program itself may work in background and perform CPU->GPU and GPU->CPU data transfers all the time. For best performance it should probably transfer 20 or 30 channel streams at once: this puts a limit on how many different GPU plug-ins may run and at which sample rate, but will guarantee a no-glitch operation. In cases of mixdown bouncing, where glitch-free operation is unnecessary, processing can be switched to 'poll' mode (for better than real-time performance).

GPU plug-ins will have to connect to that 'gpuhost' program and request an I/O stream. Since GPU processing is asynchronous in relation to native audio host processing, 'gpuhost' program should perform the necessary data synchronization and return processed data with standard delay (for example, 2048 samples - this can be made configurable).

In the extreme, this 'gpuhost' program can be made a standard application with some open API that can load plug-in vendor GPU code, and send parametric data from plug-in to GPU code: all in a way much like DSP cards do this.

BTW, it seems that triple buffering should be used with GPU processing. Double-buffering fails a lot.

Nils Schneider · Post by **Nils Schneider** » Fri Oct 06, 2006 2:49 pm

This sounds quite good to me, good ideas. But I think for a first test release, it's not bad at all. Sure, there are always people that are requesting things that just cannot be handled (e.g. supporting Geforce 2 or intel extreme graphics 2 video cards ), but whatever you release: trouble is always there, even with commercial apps.

I released it because no other did, and someone HAS to prove that it's working, and it is

How far is your progress? Already something that someone is able to listen to, maybe as an offline process?

Nils Schneider · Post by **Nils Schneider** » Fri Oct 06, 2006 2:50 pm

Ah i forgot to mention I can easily switch to OpenGL by just one line of code, but my video card doesn't support floating point render targets under openGL so I set it to D3D as default.

english · Post by **english** » Fri Oct 06, 2006 2:52 pm

You two need to get together and make beautiful code with each other

eng

duncanparsons · Post by **duncanparsons** » Fri Oct 06, 2006 2:54 pm

jens wrote:
duncanparsons wrote:His real name is Gol..

yeah, sure...

quid?

Check the famous aliasing thread, and you can see where the kvr-handle has changed, but the text hasn't..

maybe gol was a pseudonym too.. I'm trying to care

DSP

Aleksey Vaneev · Post by **Aleksey Vaneev** » Fri Oct 06, 2006 2:59 pm

Nils Schneider wrote:How far is your progress? Already something that someone is able to listen to, maybe as an offline process?

Of course, that convolution reverb I was referring is working. But it is working unstably. Since I was not coding it myself (other than VST implementation), I cannot change anything in it. But in any case, according to those ideas I've posted here, it needs a full re-implementing. Otherwise stable and commercially-competitive GPU processing is unrealizable.

However, absense of 64-bit floating point processing on graphics cards still puts GPU processing on a lower level sound quality-wise. Especially for convolution and FFT code which sound far from being pristine when calculated using 32-bit floats.

munchkin · Post by **munchkin** » Fri Oct 06, 2006 3:06 pm

It seems to be working on my PC without glitches so something must be right. The only thing is the slight cpu load but I understand why this happens now.

I think it's worth a few devs getting together and pushing this further. The devs can then sell us more plugins and the video card makers make some money as we all upgrade to more powerful video cards to take advantage of these new plugins. It's a win - win situation as far as I can see.

munchkin · Post by **munchkin** » Fri Oct 06, 2006 3:14 pm

The sound quality of the GPU Delay is as good as if not better than some of my paid for delays so it doesn't sound as if sound quality is compromised by using the GPU.

Aleksey Vaneev · Post by **Aleksey Vaneev** » Fri Oct 06, 2006 3:18 pm

munchkin wrote:The sound quality of the GPU Delay is as good as if not better than some of my paid for delays so it doesn't sound as if sound quality is compromised by using the GPU.

Sure, but convolution-based filtering and FFT-based algorithms will suffer a loss in comparison to 64-bit FP.

Nils Schneider · Post by **Nils Schneider** » Fri Oct 06, 2006 3:25 pm

@Aleksey Vaneev I'm not deep enough into fft and convolution to say if 64 bit are really required to get a good sound quality, but I know that older radeon cards only have an internal resolution of 24 bit for all floating point values, while nvidia cards always had 32 bit (float) and 16 bit (half, which is 16bit floating point). So if you've tested on a radeon card, this may cause the bad sound quality

GPU Delay - A delay plugin running on a graphics card