# NVMe vs SATA SSD - any measurable benefit for audio?



## keyman_sam

Hi All,

Has anyone run any benchmarks on performance between NVMe SSD vs SATA for audio? Is it overkill for us? Does it give any measurable advantage or shall we stick with SATA SSDs?


----------



## Gerhard Westphalen

For the sake of clarity, I think this should be split into 4 categories -

1. Snappiness of starting and running programs (does Cubase get laggy with large sessions...)

2. Number of audio tracks that can be played (or recorded)

3. Project load times - project file and samples

4. Number of voices that can be streamed

For me personally, I'd care about #2 and #4. Normal SSD performance is fine for me for #1 and #3. Even #2, I don't think I've ever maxed out an SSD in terms of playing back audio tracks from it but there are people who need to play and record hundreds of tracks at 192kHz. So I'm really only interested in #4.


----------



## EvilDragon

#4 is also a non-issue mostly with SATA SSDs. Your CPU might falter sooner than SSD gets oversatured...


----------



## Gerhard Westphalen

EvilDragon said:


> #4 is also a non-issue mostly with SATA SSDs. Your CPU might falter sooner than SSD gets oversatured...


Based on my past experiences, I had to split my samples onto multiple SSDs as I was maxing them out. I don't remember what my preload buffer is set at (maybe 12 for most patches) but I need 4 SSDs to run my orchestral template. A single big SSD wouldn't be able to handle it. I'm not sure if using NVMe would help with that. Perhaps there's still a bottleneck at the CPU in terms of processing the stream from a single drive vs multiple so NVMe wouldn't help and I'd still need multiple drives.


----------



## EvilDragon

Well, it's always a good idea to split things out some. It was the case back when we all used spinning rust, it's still valid with SSDs. But I must say when I loaded a bunch of stuff that's all located on a single SATA SSD (lots of Spitfire and NI stuff, say), I didn't have any issues whatsoever.

One thing to be aware of, though - Kontakt doesn't fully utilize SSDs as far as queue depth is concerned (this is what Tack discovered and documented), it very rarely goes to QD2, it's all QD1 (which makes sense since when Kontakt was conceived there _were_ no SSDs, all I/O was pretty much serial rather than having some large queue depths), and we all know SSDs do the most IOPS with larger queue depths, like QD32. So now that I mention this, NVMe might help somewhat, but it won't be fully utilized either (won't be reaching the max possible IOPS). So there needs to be some work done on Kontakt's engine itself (and this is kinda tricky). Then even regular SATA drives will be able to provide a lot more concurrent voices than what they can do now.


----------



## keyman_sam

Gerhard Westphalen said:


> For the sake of clarity, I think this should be split into 4 categories -
> 
> 1. Snappiness of starting and running programs (does Cubase get laggy with large sessions...)
> 
> 2. Number of audio tracks that can be played (or recorded)
> 
> 3. Project load times - project file and samples
> 
> 4. Number of voices that can be streamed
> 
> For me personally, I'd care about #2 and #4. Normal SSD performance is fine for me for #1 and #3. Even #2, I don't think I've ever maxed out an SSD in terms of playing back audio tracks from it but there are people who need to play and record hundreds of tracks at 192kHz. So I'm really only interested in #4.



Same here. #2 & #4 are what I care about the most. 

Another thing to keep in mind - EW Play can utilize SSDs well. If there's not a whole lot of benefit for #2 and #4 I might stick with a $20 enclosure for my sata ssd.


----------



## tack

I looked into #3 for Kontakt and particularly the aspect of project loading where the UI was blocked (since that was the most annoying for me, whereas background loading of samples didn't bother me much).

Documented here.

Conclusion: NVMe doesn't help projects using Kontakt to load faster to the point where the UI is unblocked. But NVMe does help background loading of samples. The write-up goes into why, but ED summarized it well enough above that it's caused by lack of parallel I/O resulting in low queue depth.

Been meaning to look into #4 especially as it relates to different preload buffer sizes but haven't yet .


----------



## HelixK

EvilDragon said:


> So there needs to be some work done on Kontakt's engine itself (and this is kinda tricky). Then even regular SATA drives will be able to provide a lot more concurrent voices than what they can do now.



Realistically speaking, is this kind of engine rewrite to be expected at all? After Kontakt 6 I'm not so confident that NI has any interest in touching their old code.


----------



## EvilDragon

It's not unrealistic to see improvements in DFD performance at some point. Also, we're not talking about whole engine rewrite at all - this is not necessary as Kontakt is still the most performant sampler out there. Only a certain aspect of the engine needs some updates. It is not a straightforward thing to do, but it's also not impossible.

https://www.native-instruments.com/...oad-buffer-sizes-for-different-drives.317528/

Dinos is product owner of Kontakt. While nothing was promised in his post, to me it does sound encouraging. As he said there, benefits of such a feature as suggested there are obvious (as an aside, I have pointed out Tack's exploratory document to Dinos as well regarding SSD QD levels and other arcana, so they are all aware of it).


----------



## keyman_sam

Kontakt aside, is there any advantage for project audio, say for Cubase?


----------



## EvilDragon

Sure, if you're recording and/or playing back a huge amount of tracks...


----------



## Fox

Can I tag on this question: 

Is there a significant decrease in speeds for a Samsung 860 EVO 2TB in an external enclosure (say, a Sabrent 2.5-Inch SATA to USB 3.0 Tool-free External Hard Drive Enclosure)...

vs.

...a Samsung SSD T5 2TB?


----------



## Damarus

Fox said:


> Can I tag on this question:
> 
> Is there a significant decrease in speeds for a Samsung 860 EVO 2TB in an external enclosure (say, a Sabrent 2.5-Inch SATA to USB 3.0 Tool-free External Hard Drive Enclosure)...
> 
> vs.
> 
> ...a Samsung SSD T5 2TB?



Probably not. The T5 supports USB 3.1 if you have that on your computer, which can be double the speed of 3.0.


----------



## ABalvin

Gerhard Westphalen said:


> Based on my past experiences, I had to split my samples onto multiple SSDs as I was maxing them out. I don't remember what my preload buffer is set at (maybe 12 for most patches) but I need 4 SSDs to run my orchestral template. A single big SSD wouldn't be able to handle it. I'm not sure if using NVMe would help with that. Perhaps there's still a bottleneck at the CPU in terms of processing the stream from a single drive vs multiple so NVMe wouldn't help and I'd still need multiple drives.


Do you think this bottleneck would happen if i have 4 NVMe SSDs inside 1 Enclosure (Express 4M2/ OWC) connected via Thunderbolt 3.
Because at the moment i have 2 1TB NVM SSDs inside this enclosure, but im debating if i should add 1 or 2 more SSDs (it can host up to 4 SSDs) or if this would cause a bottleneck, because in the end all the SSDs would be streaming from just 1 Thunderbolt 3 connection.


----------



## Gerhard Westphalen

ABalvin said:


> Do you think this bottleneck would happen if i have 4 NVMe SSDs inside 1 Enclosure (Express 4M2/ OWC) connected via Thunderbolt 3.
> Because at the moment i have 2 1TB NVM SSDs inside this enclosure, but im debating if i should add 1 or 2 more SSDs (it can host up to 4 SSDs) or if this would cause a bottleneck, because in the end all the SSDs would be streaming from just 1 Thunderbolt 3 connection.


I'm not sure


----------



## James Everingham

I recently tested a Samsung 970 Evo NVMe against an 860 Evo SATA SSD as projects drive, and while perhaps expecting some faster autosave and project load times, the difference was negligible in practise. I do have a 960 Pro NVMe as primary samples drive and given my personal (slightly weird) workflow, the difference is outstanding


----------



## Dewdman42

Can you describe your slightly weird workflow that gives you outstanding sample load times?


----------



## InLight-Tone

James Everingham said:


> I recently tested a Samsung 970 Evo NVMe against an 860 Evo SATA SSD as projects drive, and while perhaps expecting some faster autosave and project load times, the difference was negligible in practise. I do have a 960 Pro NVMe as primary samples drive and given my personal (slightly weird) workflow, the difference is outstanding


I'm interested in your experience using these drives as sample drives. How about Kontakt settings? I primarily use a disabled Instrument track in Cubase, so faster load times after activating the track would be welcome though nothing to complain about already...


----------



## James Everingham

Dewdman42 said:


> Can you describe your slightly weird workflow that gives you outstanding sample load times?


Template is basically constructed of track presets and controlled via touchscreen software, so no conventional template with pre-loaded instruments via VEP. So with each 'new' track in the session, a new Kontakt instrument is loaded. So you want the fastest sample loading time from patch selection to the patch being playable (not noticed so much effect on the loading time of the actual patch itself). Futureproofing was another consideration when I had my current rig built...and with M.2 basically PCIe 3.0 x4 the potential is there for crazy rates if not bottlenecked. Maybe it's other components doing the work, but my experience is slicker with samples on the NVMe, at least compared to my previous rig, which was 850 Pro SATA SSDs in BMD Multidock over TB2


----------



## chimuelo

I load my template and leave it be as the Samsung Pro-line SSDs is plenty for my needs.
But the Samsung NVMe and it’s Caching software really make a difference loading large samples in Omnisphere when using Keyscape.
If you’re just using Omni the samples are PCM and load quickly, but with Keyscape it’s quite noticeable. I need this because the 4 part Multis don’t retain patches that are in use at the moment, and just reloads everything.
So faster is better.

I use to love the way certain old samplers would notice an instrument from a performance is the same and only load samples not already in use.
That’s a software controlled option on hardware, it’s not like it was magical hardware.
Someday this will be universal I hope.

In this day and age Im surprised we just can’t have our Templates converted to ROM.


----------



## Prockamanisc

I would add a #5 for myself- when I save an instrument as a Track Preset in Cubase and reload it, some of the tracks take a couple of seconds to load (Spitfire), and some of them take more than a few seconds to load (Dimension Strings). Is this something that would be sped up with an NVMe?


----------



## Gerhard Westphalen

Prockamanisc said:


> I would add a #5 for myself- when I save an instrument as a Track Preset in Cubase and reload it, some of the tracks take a couple of seconds to load (Spitfire), and some of them take more than a few seconds to load (Dimension Strings). Is this something that would be sped up with an NVMe?


What is it that takes this time? Does Cubase just give you a spinning wheel?


----------



## Prockamanisc

Gerhard Westphalen said:


> What is it that takes this time? Does Cubase just give you a spinning wheel?


Yes, exactly. When I hit the refresh circle to reload a disabled Track Preset, some of them take longer than others to respond. As I remember, it just sits there unresponsive for varying lengths, depending on the instrument that's being re-loaded.


----------



## Gerhard Westphalen

Prockamanisc said:


> Yes, exactly. When I hit the refresh circle to reload a disabled Track Preset, some of them take longer than others to respond. As I remember, it just sits there unresponsive for varying lengths, depending on the instrument that's being re-loaded.


I could be wrong but I think it's the time it takes for Cubase to load up the vst (unless you're getting different times for different Kontakt tracks) so that would be #1. In other words, I think putting your OS on NVMe could potentially improve it.


----------



## Prockamanisc

In Cubase, does having all of your samples on NVMe drives allow you to decrease the buffer size? Does it improve latency at all? I'm wondering if I'm going to swap out my SSD's for NVMe's, but I wouldn't wanna invest that much if it's only for faster instrument loading times. Latency has always been the #1 enemy.


----------



## EvilDragon

You wouldn't gain anything except loading times by going NVMe.


----------



## DAW PLUS

The main issue with sample loading is that it is done sequentially instead of parallel, at least that is what it looks like to me.
Project drives don't need NVMe unless you keep your 4K videos in the project folder, but most use 1080p or less so a SATA handles that fine. 
You can *overdub* 1000 tracks easily on a SATA SSD.


----------



## TonalDynamics

DAW PLUS said:


> The main issue with sample loading is that it is done sequentially instead of parallel



I don't understand that, frankly. It's not like it's being written from one drive to the next, it's being loaded into RAM. Surely this could at least be programmed to take advantage of Dual/Quad-channel more effectively?

Feels like it should, at some level, be open to parallelization
🤷‍♂️

Basically my prevailing sentiment is that Kontakt is ancient, dated and not upgraded simply because there isn't any real competition. A pity...


----------



## Ivan M.

tack said:


> I looked into #3 for Kontakt and particularly the aspect of project loading where the UI was blocked (since that was the most annoying for me, whereas background loading of samples didn't bother me much).
> 
> Documented here.
> 
> Conclusion: NVMe doesn't help projects using Kontakt to load faster to the point where the UI is unblocked. But NVMe does help background loading of samples. The write-up goes into why, but ED summarized it well enough above that it's caused by lack of parallel I/O resulting in low queue depth.
> 
> Been meaning to look into #4 especially as it relates to different preload buffer sizes but haven't yet .





> In this short 13ms snippet (representative of the entire process), we see Kontakt continuously opening, reading a bit, and closing the same file over and over again. It seems to close and reopen the file when it’s done reading a sequential bit of data and wants to skip ahead into the file.



Did you get a chance to retest this? Is it still an issue?


----------



## tack

Ivan M. said:


> Did you get a chance to retest this? Is it still an issue?


I just checked with the latest Kontakt, and it still has this behavior.


----------



## TonalDynamics

tack said:


> Conclusion: NVMe doesn't help projects using Kontakt to load faster to the point where the UI is unblocked



I'm not quite clear what you mean, are you talking about loading libraries and having the UI actually be unresponsive during the load period?

Because if so AFAIK I got rid of that issue by batch-resaving every instrument in question, and then turning on 'enable background loading of samples' or some such setting in Kontakt.

The 'UI-loading' period went from say 10 seconds on average to maybe 300 ms or so (guesstimating)

Basically if you have an SSD and you do both of those things you should not have your UI freeze up anymore while loading samples, unless you're loading say 100 at a time (in my experience)


----------



## tack

TonalDynamics said:


> I'm not quite clear what you mean, are you talking about loading libraries and having the UI actually be unresponsive during the load period?


Yep.



TonalDynamics said:


> Basically if you have an SSD and you do both of those things you should not have your UI freeze up anymore while loading samples, unless you're loading say 100 at a time (in my experience)


But that's exactly the rub: when you're loading a project with 100+ patches. Each patch maybe takes 300-500ms to load -- which, with background sample loading, is almost entirely CPU-bound -- and so during project loads, the UI is blocked for 30-50 seconds (in that example).


----------



## TonalDynamics

tack said:


> Yep.
> 
> 
> But that's exactly the rub: when you're loading a project with 100+ patches. Each patch maybe takes 300-500ms to load -- which, with background sample loading, is almost entirely CPU-bound -- and so during project loads, the UI is blocked for 30-50 seconds (in that example).


Right, it's definitely a nuisance.

The only real solution in my eyes is to load the darn thing and just keep it open all day TBH, and in the scheme of things I feel like although it's probably a worthy upgrade, it's something you should do last after upgrading all the other components in your system if you already have decent SSDs.

YMMV of course but that's my take on it


----------



## chimuelo

Still using NVMe for Omnisphere because it allows me to stay out of Live/Dual mode by not keeping samples loaded on multiple MIDI Channels. It loads Keyscape C7/LA Rhodes instantly, well enough to be playable (polyphony limited) until entire samples are loaded.

The only storage solution I’ve seen to show noticeable differences over SSDs is the Intel Optane 905P devices. Super low latency, incredible random reads and transaction time. Helpful for real time live work, but recording is never something needing immediacy like that.

As long as sample buffers are still loaded into RAM I doubt Storage devices regardless of benchmarks, will make any significant differences.

We were spoiled in 1995 to have Gigastudio. 25 years later we see the biggest improvement was SSDs. My ancient GSIF/Scope rig with a 1.4GHz Tualitin CPU still kicks butt. That was a 6,000 dollar 4U rig.

TigerLake/Vermeer w/ PCI-4.0 won’t be a big deal either.
More instances snd slightly better latency.

Concentrate on the music, it will take you further than more toys.


----------



## georgedavid98

Hey guys I really need some help,

I have 2.3ghz i5 250gb macbook 2018. I am using Logic Pro X, and many times have experienced system overload. Did all that buffering/latency adjustment bla bla. I upgraded to some setup; maschine, komplete kontrol etc. And the system overload is far more present now...

I was advised to get an SSD. Would that help? And which one is it doable? For instance if I get the Samsung 970, would make no difference in its speed and workflow since I am obliged to use a USB cable filtering the the mbps right? 

Will appreciate your help with this.


----------



## Dracarys

georgedavid98 said:


> Hey guys I really need some help,
> 
> I have 2.3ghz i5 250gb macbook 2018. I am using Logic Pro X, and many times have experienced system overload. Did all that buffering/latency adjustment bla bla. I upgraded to some setup; maschine, komplete kontrol etc. And the system overload is far more present now...
> 
> I was advised to get an SSD. Would that help? And which one is it doable? For instance if I get the Samsung 970, would make no difference in its speed and workflow since I am obliged to use a USB cable filtering the the mbps right?
> 
> Will appreciate your help with this.


Is your macbook able to have 2 internal drives? If so get another 2tb internal Sata ssd. 

If you have to use an external ssd, get a 2tb NVMe, then get an adapter (m.2 to USB). The NVMe drives are pretty much the same price as SATA. With an external NVMe ssd, you'll be capped at 1000mb/s reads because of the usb 2.0, 3.0, or USB C port. If you get an external SATA ssd, you'll get around 500mb/s reads. So, no point in an external sata SSD, same price and less speed.

Also, make sure the external ssd is NVMe and not just M.2 SATA. M.2 is only the connector, NVMe and SATA are the speeds.


----------



## Publius

It is helpful to distinguish between nvme and sata ssd, given a 10:1 speed ratio. Also, if reads are sequential, iops might be a good measure. I don’t know that nvme is needed, but we have two very different devices with the same generic name.


----------



## ridgero

georgedavid98 said:


> Hey guys I really need some help,
> 
> I have 2.3ghz i5 250gb macbook 2018. I am using Logic Pro X, and many times have experienced system overload. Did all that buffering/latency adjustment bla bla. I upgraded to some setup; maschine, komplete kontrol etc. And the system overload is far more present now...
> 
> I was advised to get an SSD. Would that help? And which one is it doable? For instance if I get the Samsung 970, would make no difference in its speed and workflow since I am obliged to use a USB cable filtering the the mbps right?
> 
> Will appreciate your help with this.


Why do you relate the "System Overload" to the SSD? 

In your case, the bottleneck is most likely your CPU and and RAM


----------



## gzapper

georgedavid98 said:


> Hey guys I really need some help,
> 
> I have 2.3ghz i5 250gb macbook 2018. I am using Logic Pro X, and many times have experienced system overload. Did all that buffering/latency adjustment bla bla. I upgraded to some setup; maschine, komplete kontrol etc. And the system overload is far more present now...
> 
> I was advised to get an SSD. Would that help? And which one is it doable? For instance if I get the Samsung 970, would make no difference in its speed and workflow since I am obliged to use a USB cable filtering the the mbps right?
> 
> Will appreciate your help with this.


2018 Macbook pro's aren't upgradeable. You're stuck with the RAM and drive. If its only a 250Gb drive its likely getting full and slowing the system. An external drive will help there, but otherwise its likely you're running out of RAM or you're taxing the processor and the computer is running its fan on full and throttling the system to keep from overheating.


----------

