KVR Audio

Kaine · Post by **Kaine** » Tue Aug 15, 2017 4:07 pm

Another first look as Theadripper lands with us : http://www.scanproaudio.info/2017/08/14 ... 20x-1950x/

incubus · Post by **incubus** » Tue Aug 15, 2017 7:06 pm

This should be a sticky. ^^^

Still a little confused with ASIO users in the 128 buffer range. For me I need ASIO performance > instances. Frankly, I'd want to go to 64 buffer/44.1k if I upgraded my chip (playing bass and guitar you can feel a difference w/o doubt) so these crazy-core chips may still be an issue for me?

camsr · Post by **camsr** » Wed Aug 16, 2017 1:38 pm

Thanks for such a well written and thorough article

Kaine · Post by **Kaine** » Wed Aug 16, 2017 4:28 pm

incubus wrote: Still a little confused with ASIO users in the 128 buffer range. For me I need ASIO performance > instances. Frankly, I'd want to go to 64 buffer/44.1k if I upgraded my chip (playing bass and guitar you can feel a difference w/o doubt) so these crazy-core chips may still be an issue for me?

The latency response itself will be more driver dependent, so that shouldn't really factor in it. What the results outline is how much you can run at the buffer settings rather than how responsive they will be.

If you have a 10 track project with little more than eqs and some compression then anything on that chart would walk it. At that point you start to consider if you can improve the interface performance in anyway.

pljones · Post by **pljones** » Wed Aug 16, 2017 5:08 pm

Yeah, I guess it's down to total system throughput. I've got my (drum multi-) samples on NVMe SSD with RAM running as fast as my FX8350 will take it, but getting mixed samples down the FireWire port at below 160 samples per buffer becomes unreliable, which is a bit of a pain. I even get glitching now and then at that. There's little point running more threads and a paired CPU design sounds like it can only make things worse when sample data might end up getting put in the wrong place.

Debutante · Post by **Debutante** » Thu Aug 17, 2017 3:52 am

Firstly, way to break shit down.

Secondly, this stinks!! I was SOOOOO looking forward to a dual system. This numa numa crap hits pretty hard. Even buying a super big chip might be no good

who fixes this shit!!! the chip maker, the os, or the sotftware dev - its the chips isnt it

DJ Warmonger · Post by **DJ Warmonger** » Thu Aug 17, 2017 4:11 am

Multi-threaded synths. DSP-intensive, please.

No one runs 400 compressors in a project. Also, Kontakt as a sampler is expected to be memory bound, rather than DSP-bound.

incubus · Post by **incubus** » Thu Aug 17, 2017 5:39 am

DJ Warmonger wrote:Multi-threaded synths. DSP-intensive, please.

No one runs 400 compressors in a project. Also, Kontakt as a sampler is expected to be memory bound, rather than DSP-bound.

Man, you are no fun. I want crushing DEATH! I want 6000 instances of diva and the CPU doing this:

Er, on a serious note, kontakt has been known to hit the CPU (especially S1) pretty hard, so........

DJ Warmonger · Post by **DJ Warmonger** » Thu Aug 17, 2017 5:54 am

incubus wrote:
DJ Warmonger wrote: Er, on a serious note, kontakt has been known to hit the CPU (especially S1) pretty hard, so........

Possibly, never used it anyway

kmonkey · Post by **kmonkey** » Thu Aug 17, 2017 6:10 am

incubus wrote:
Er, on a serious note, kontakt has been known to hit the CPU (especially S1) pretty hard, so........

I truly never saw kontakt using my CPU in significant amount. Memory yes but CPU not. And i am using Ableton Live which is not last word in CPU optimal resource usage...

Looking forward for more Threadripper DAW stories.

Kaine · Post by **Kaine** » Thu Aug 17, 2017 3:03 pm

Debutante wrote: Secondly, this stinks!! I was SOOOOO looking forward to a dual system. This numa numa crap hits pretty hard. Even buying a super big chip might be no good

who fixes this shit!!! the chip maker, the os, or the sotftware dev - its the chips isnt it

Chipset mostly and then software balancing I'd say. Given some of this is to do with physical distance covered by the data, I'm not sure how you'd even work around that, the impression I get is that they've been trying to crack it for decades now.

A lot of this isn't a problem for a lot of scenarios. Servers focus on an optimized NUMA design because they don't need to work with real time processing most of the time. When the average workload is offline rendering or database management NUMA is awesome.

DJ Warmonger wrote:Multi-threaded synths. DSP-intensive, please.

If you design the test using currently freely available tools and forward over the project file, I will happily run it when I'm testing and add it to the results.

DJ Warmonger wrote: No one runs 400 compressors in a project.

No, but then if you mix and match your plugins, how exactly is it going to work?

The more you put in a channel chain, the quicker 1 channel is going to tip it over the edge.

If you have a channel chain with Synth > EQ > distortion > Compressor > Reverb then you might overload it at 70% as the first channel goes, then your measurement is inaccurate because your not accounting for how many instances a lesser channel chain might manage.

The point of the test is to use it as a repeatable baseline metric that can measure as much of the power as possible. The more complex the chain the more likely the test is to start missing overhead due to early overloads.

DJ Warmonger wrote:Also, Kontakt as a sampler is expected to be memory bound, rather than DSP-bound.

The loaded audio is pretty minimal with the test itself running in a few GB. The are a set number of Kontakt instances open and then you increase the number of notes being played within the midi score to raise the polyphony.

I had 32GB in the test bench this time although normally it's only 8GB or 16GB with pretty much 80% of the RAM left empty in use whist the benchmark is open. What the test is doing is forcing each loaded Kontakt module to do is generate a stack of polyphony which in itself is CPU dependent.

The only reason I threw so much RAM in there this time, was because one of the gamers here complained that the overclock went out the window with more than 16GB in it, and I wanted to have a tweak about with his profiles whilst I was testing.

pljones · Post by **pljones** » Thu Aug 17, 2017 5:59 pm

Kaine wrote:
DJ Warmonger wrote:Also, Kontakt as a sampler is expected to be memory bound, rather than DSP-bound.
The loaded audio is pretty minimal with the test itself running in a few GB. The are a set number of Kontakt instances open and then you increase the number of notes being played within the midi score to raise the polyphony.

This, entirely, is my main problem - I need polyphony (multiple notes, multiple mics per note, long note tails) with spare CPU for the additional effects (compression and reverb mainly). I don't see my CPU maxing out, so I'm assuming in my case glitches are caused by overloading RAM throughput but I could be wrong... a buffer dropped is a buffer dropped, though.

andre h · Post by **andre h** » Fri Aug 18, 2017 11:32 am

is this the cause of the underwhelming 1950X DSP results?: https://helpcenter.steinberg.de/hc/en-u ... CPU-setups

incubus · Post by **incubus** » Fri Aug 18, 2017 8:29 pm

This is what I mentioned in another thread and kinda got blasted on. How many cores can you host handle? More than 14 is NOT good because some makers don't have the tech yet to take advantage of this yet.

So, since I never hear anyone complain about intel i7 6 core systems, isn't that the sweet spot right now?

Debutante · Post by **Debutante** » Sat Aug 19, 2017 7:02 am

incubus wrote:This is what I mentioned in another thread and kinda got blasted on. How many cores can you host handle? More than 14 is NOT good because some makers don't have the tech yet to take advantage of this yet.

So, since I never hear anyone complain about intel i7 6 core systems, isn't that the sweet spot right now?

That's only on Windows 10 by the looks of things. What they need is intergrated memory with infinity fabric between memory and cpu. Problem Solved.

Threadripper first look