NVMe vs SATA SSD - any measurable benefit for audio?
- Thread starter keyman_sam
- Start date
Gerhard Westphalen
Mastering Engineer (occasionally Scoring Mixer)
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.
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
KSP Wizard
#4 is also a non-issue mostly with SATA SSDs. Your CPU might falter sooner than SSD gets oversatured...
Gerhard Westphalen
Mastering Engineer (occasionally Scoring Mixer)
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
KSP Wizard
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.
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
New Member
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
Damned Dirty Ape
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 .
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 .
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
KSP Wizard
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).
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
New Member
Kontakt aside, is there any advantage for project audio, say for Cubase?
EvilDragon
KSP Wizard
Sure, if you're recording and/or playing back a huge amount of tracks...
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
Mastering Engineer (occasionally Scoring Mixer)
I'm not sure
James Everingham
Member
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
InLight-Tone
Senior Member
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
Member
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
Last edited:
chimuelo
Star Of Stage & Screen
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.
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.
