CPU Performance vs. Real-Time Performance in Digital Audio Workstations

[benny van de locht]

Ben,
What trackcount would you suggest, and does it have to have actual audio in it?
And what plugin would you think of, Dynomyte?
If I can, I would like to make the test. But I might need some tips.
Can I just save the test as a project and upload it, so anyone could open it and enable plugins untill dropouts start to occur? Or add them for themselves?

Benny

[Frank]

Ben,
What trackcount would you suggest, and does it have to have actual audio in it?
And what plugin would you think of, Dynomyte?
If I can, I would like to make the test. But I might need some tips.
Can I just save the test as a project and upload it, so anyone could open it and enable plugins untill dropouts start to occur? Or add them for themselves?

Benny

Shhhht Ben is Busy !! 3.4 3.4 !!

We should first define our test goals

regards

[benny van de locht]

Ben,
What trackcount would you suggest, and does it have to have actual audio in it?
And what plugin would you think of, Dynomyte?
If I can, I would like to make the test. But I might need some tips.
Can I just save the test as a project and upload it, so anyone could open it and enable plugins untill dropouts start to occur? Or add them for themselves?

Benny

Shhhht Ben is Busy !! 3.4 3.4 !!

We should first define our test goals

regards

You're right Frank.

[micksedan]

Running loads of plugins isn't the way to go (as I now), but choosing a new audio interface, it's certainly a factor I would look after knowing that plugins will demand more and more as developers compile new revolutionary milestone plugins.
Benny.

Using U-he's Diva synth as an example, to help aleviate some of the extreme
cpu usage needed for it's dedicated use case, they chose to implement
3 quality levels, on behalf of customers using slow computers,
while finding ways to optimize the cpu munching over time.

They also began releasing experimental test plugins, to gather real-world
data, opinions, and experience examples from their userbase. While educating
their users quite nicely about synthesizer creation, along the way.
The U-he plugins run very nicely in linux Mixbus!

[haraldthi]

That is a great video... It did make me wonder if adding a video card for my monitor would be helpful in DAW performance. I don't have any issues, but it would be nice to add ant further improvement I could. What do you all think add a video card or keep running off the motherboard?

Cole

I wondered about this too.
I noticed when getting near to my maximum cpu usage (the parameter in Mixbus, definatly not on taskmanager), I heard crackling when manipulating the GUI. Can a discrete (passive) graphics card contribute to the maximum plugin overhead?

Benny

Difficult to say if a video card will help: Mixbus does not need complicated graphics.
It will enlarge you memory : it will use the memory on the card instead of the system memory.
Most probably if one has an older system with a limited gpu on the motherboard, it will increase performance

But the in CPU i7 GPU is on the fastest bus. The internal CPU=CPU bus. Getting data over the PCie bus, to the external GPU most likely will need more CPU cycles to get the data across

I am about to start a series of tests: One of them is comparing the performance of the external GPU with the internal. It is on a MAC but it will give an indication

regards

If so, it's kind of a pity.
The video editing industry is making good use of GPUs for mathematical heavy-lifting and DAWs and plugins could do the same.
It may not be the best thing to do if there's a lot of traffic between CPU and GPU, but for calculations you can easily run in parallell, like Fast Fourier Transforms, it's a godsend.
So I really hope we'll see more GPU programming skills in the audio industry, too.

[Matt]

That is a great video... It did make me wonder if adding a video card for my monitor would be helpful in DAW performance. I don't have any issues, but it would be nice to add ant further improvement I could. What do you all think add a video card or keep running off the motherboard?

Cole

I wondered about this too.
I noticed when getting near to my maximum cpu usage (the parameter in Mixbus, definatly not on taskmanager), I heard crackling when manipulating the GUI. Can a discrete (passive) graphics card contribute to the maximum plugin overhead?

Benny

Difficult to say if a video card will help: Mixbus does not need complicated graphics.
It will enlarge you memory : it will use the memory on the card instead of the system memory.
Most probably if one has an older system with a limited gpu on the motherboard, it will increase performance

But the in CPU i7 GPU is on the fastest bus. The internal CPU=CPU bus. Getting data over the PCie bus, to the external GPU most likely will need more CPU cycles to get the data across

I am about to start a series of tests: One of them is comparing the performance of the external GPU with the internal. It is on a MAC but it will give an indication

regards

If so, it's kind of a pity.
The video editing industry is making good use of GPUs for mathematical heavy-lifting and DAWs and plugins could do the same.
It may not be the best thing to do if there's a lot of traffic between CPU and GPU, but for calculations you can easily run in parallell, like Fast Fourier Transforms, it's a godsend.
So I really hope we'll see more GPU programming skills in the audio industry, too.

I've seen some talk about using the GPU for audio processing. And it's not ideal.

All apologies if I get some terms/info wrong, but here's my understanding. And feel free to correct me.

Apparently GPU's are fast and can do a lot of math, but it's not very "deterministic". In other words it can promise it will be done in "x" amount of cycles. Which is necessary for audio. You set your playback buffer to say 512 samples. Whichever processor has to have the work done by then. If it's late then it will obviously cause issues. CPU's are better and can be shoehorned to be pretty deterministic. But aren't ideal. That's why there have been kernel's developed for Linux for audio. They help make the CPU even more deterministic. The best is still DSP. You know exactly how much power and how fast it is. So there are no surprises. CPU's and GPU's can also spike and cause problems. DSP's know what they can and can't do.

No for non-realtime bouncing a gpu might be able to be utilized. Not sure. But I wouldn't hold my breathe on seeing them used during mixing.

And slightly jumping subjects. I'm kind of interested in reading more into fpga chips. Antelope audio is using them in their interfaces. And Microsoft has started incorporating them into their servers. Seems they could be the next "DSP" for lots of things. Including audio.

[sunrat]

And slightly jumping subjects. I'm kind of interested in reading more into fpga chips. Antelope audio is using them in their interfaces. And Microsoft has started incorporating them into their servers. Seems they could be the next "DSP" for lots of things. Including audio.

Digico uses FPGA for audio processing in their consoles, plus DSP for effects.

[Ben@Harrison]

@Matt, you are right. Video cards are designed to do a lot of math, and return the results to the main processor within 1/60th of a second, or similar. And if you "miss" a video frame, it is very unlikely that the user will notice. Whereas a soundcard might require updating every 5ms ( 1/200th of a second ), and a missed deadline will be a potentially session-killing "click".

Furthermore, GPU/FPGA's are designed to do very repetitive work on a huge dataset. The processor can run multiple streams and do the same operations on every stream, in parallel. Whereas with audio, every stream (track) is entirely independent and might have a wide range of operations depending on the plugins and processor-order that the user has chosen.

In a dedicated console you can use an FPGA or whatever. But DAW/plugin developers have very little control over what hardware the user has, and whether it will still be available next year. So we have to target the plain-old CPU.

-Ben

[x42]

"return the results to the main processor within 1/60th of a second" is not necessarily true. The vast majority of GPU only can write produced data out to a screen port. The throughput for reading back to the CPU is small.

[allank]

Hmm .. I run Linux and would be interested in this test .. I have a couple of different machines I could test from..
I do have a very powerful CPU on my studio machine Intel 4930k . clocked at 4.2 GHZ.. My office computer is an AMD 7860k
I usually run at 128 periods with a buffer of 3 for mixing.. (i've been playing with Bitwig as an eventual replacement for my AKAI MPC 2500, so to get even remotely comparable latency to the AKAI I need to run at 32 periods, and the system copes)

I don't see DSP going much higher than 25% for around 24 tracks.. Although I don't use a huge number of plugins, and if I do, it's usually a mix of Harrison plugins and either x42 EQ or Linux DSP eq (although they are called something else now). Those plugins tend to be more efficient. I have used open source LV2 compression plugins, but not since I started using 32c.

The soundcard/converters (whatever you want to call them) does seem to make a difference, the M-AUDIO Delta 1010 gave me better latency performance than the focusrite saffire pro10io (but worse sound).. It's hard to tell whether my A&H Zed R16 is better than the focusrite, as I upgraded my CPU at around the time I picked up that desk.

However, I've found one thing that can make a massive difference over the years is the motherboard..
A number of years back I went from a triple core AMD Phenom x3 720 to a hex core AMD phenom2 x6 1090..... My latency performance was significantly worse on the hex core. The difference, I went from a mid-range gaming motherboard to a low end business motherboard..

Since then I've gone back to mid-upper end gaming motherboards..

I'll be happy to pass through a reference template to see what figures I can get.