Piano World Home Page Forums Our Most Popular Forums Digital Pianos - Electronic Pianos - Synths & Keyboards Will USB 3 & new ssd speeds make a difference?

Will the advent of USB 3 and the new fast SSD hard drives mean any real improvement in the playability (or sound quality) of vst piano samples?

"Improvement" means improvement over what I have now: usb 2, two first generation ssds (for various piano vsts), running on an Intel Core i7 with 12 gig mem, usb 2, some regular hard drives.
I'm assuming I'd have to replace the Gigabyte X58S-UD3 mainboard. But I don't know about the Fast Track Ultra Interface. (Currently getting 5.4 ms latency, at best).

5.4 ms is very good. I don't think you would be able detect a noticeable difference if you were to reduce your latency any further.

Drive performance won't affect latency.

1. The VST plugin or host will load the first period of each piano sample, and save in buffer memory. When you press a piano key, the sound is fetched from memory with darn near zero delay.

If you hold down the key, the software must fetch later samples from disk. But it has LOTS of time to do that ... all because the early portions of sound were instantly available from memory. Until those samples are exhausted, the sound plays uninterrupted.

Only a very slow computer will fail to keep up. (But if the computer can't keep up, as with very old computers ... you don't get latency. You get dropouts.)

So drive performance doesn't matter much anymore during performance. (It does matter if you're doing studio work, building a multi-track musical production, but I assume that's not the topic here.)

2. Latency comes from the PC sound system. The native PC audio chain introduces delay ... which is irrelevant when playing recorded music or video. But this delay is a killer when performing from a keyboard. The fix is to use an ASIO driver. (But this has NOTHING at all to do with disk drive performance.)

What affects the asio driver buffer, and therefore performance, is mainly the CPU power. So a powerful CPU will be able to handle a small buffer without cracks and pops and therefore have negligible latency. Also, the sound card has an impact, especially if the CPU is not very fast. In this case, an external card can help (I managed to run some software pianos without latency on a low power windows tablet thanks to an external card for instance...)

A faster drive can help if you're having drop-outs. Sometimes when you try to push the latency lower you can get hard drive drop-outs, depending on how the software implements streaming from disk. It's quite unusual to get a drop out on an SSD.

However, trying a lower latency will typically first expose you to bottlenecks in your audio drivers/audio device, or bottlenecks in other drivers on your system. If you're on PC, definitely check out DPC Latency Checker, which can tell you if you're getting limited in latency by your drivers. The author wrote good information on DPCs, so I won't try to explain them here.

Some of the first gen SSDs were horrible for performance consistency, every once in a while stuttering with a second of pause before continuing back to high performance. The Intel X-25s were fine, but not all the others (JMicron controllers if I recall correctly). Pretty much any new SSD this is completely inapplicable. But if you happen to have one of those old affected SSDs, you'd do well with a new one. The Samsung evos are great on performance/$ if you're shopping.

USB3 is great for external hard drives. You can stream without dropouts pretty much any software piano that exists using a modern new drive over USB3. This isn't necessarily true for USB2, or even firewire 400/800 though they're an improvement. Thunderbolt should also be great, and the internal drive interface best of all. I won't get into why unless you're interested, but with hard drives, the important things for performance are: 1) fast interface 2) using a drive with enough free space so that there's still a huge amount left over after installing, and 3) just having a huge (ideally 3TB+) drive to start with. 7200rpm vs 5400 are relatively minor considerations.

It would seem odd to me to use an SSD on USB3, since the performance would be limited by USB3, but on the plus side you could view it as getting pretty much 100% of everything USB3 can offer on performance.

Hope that helps!

Thanks very much. Very useful info.

I guess I'm good to go, even with my now 5-year-old i7/12gig/usb 2/fast track ultra set up.

Thing is, with the new really fast SSDs (Samsung) plus of course usb 3, seems to me that some of the big samples would load faster. And maybe even play more seamlessly (although most of my work is rendering my own midi files, not live playing).

I should note that when I installed the first gen SSDs (128 gigs each), I noticed a HUGE difference over my 5400 hard drives. I DID in fact get occasional pops and clicks on the "old" hard drive technology. And I'm not talking live playing; I'm talking midi files played via various piano samples, the more demanding the sample, the more pops and clicks, even when I was simply playing midi files, mind you, with some pretty demanding convolution effects!!

But once Ivory, Imperfect, Black, etc., etc... were loaded on the SSDs, the occasional pops and clicks were just GONE.

Hence the question: I'm thinking that USB 3 plus the Samsung SSDs will give me 0 errors. IE there won't even be the remotest possibility of errant hard drive behaviour.

So I get the new main board first, with usb 3, say 12-16 gigs men, and 2 512 gig Samsungs, 1000 dollar upgrade..... and what have I really gained???

Not much, except speed, I'm guessing.

But then the "weakest link" (not the TV show)? The Fast Track Ultra: that's still "state-of-the-art" in the interface department? (Here thinking of recording or studio work, rendering midi files, not live performance).

What is on your motherboard now SATA2 (3 Gbps)? A modern motherboard will have SATA3 (6 Gbps), which most modern SSDs are reaching.

While USB3 is fast (5 Gbps), you will get more bang keeping your SSDs on your motherboard.

I am not familiar with how large these samples are, but if these applications are 64 bit, with 12 GB of RAM ... I say load the whole sample into RAM (assuming you can configure that) and call it good

My main board IS old, Gigabyte x58a, and WOULD require upgrading!

If you're just playing the piano software, you won't need an SSD. It's a waste of money for this purpose. Your computer is way more powerful than what I used to use ... and everything worked fine on that old 1.7 GHz Duo with 2 GB RAM. Even with multiple pianos loaded up in Kontakt.

And the money waste would be even bigger if, as you suggest, your core computer requires an update for compatibility. Don't waste your time and money.

I'd recommend just the opposite. SSD's solved all my piano problems with Ivory II. I'd never use anything but an SSD for piano samples (or anything else - except backups) ever again. The prices on the Samsung 840 EVO's are great (heavily discounted now). But to each their own ...

I use an SSD because it's utterly silent. With a fanless power supply, and a low speed CPU fan, the computer adds no audible background noise to the piano. Though the piano operates fine with an ordinary hard drive, an SSD's speed may help with loading time for piano software or scores.

I like the lightning fast load times using SSD. Many of the sample libraries will work fine using a conventional HDD but some are borderline, notably when layering perspectives in some of those libraries which have them, so a modern SSD is the best worry-free option.

That's what I used to think too, but, as others have said, it may have an indirect affect on the latency, if it allows one to use a smaller audio buffer size. The fact that this can happen when switching to an SSD was a surprise to me, but that's the way it is. In my case, I can already use the smallest buffer size my audio interface allows (128), using an old laptop with a hard drive, so no, an SSD would not improve my latency, at least not with the sample libraries I currently use.

Note that if you only have problems when you layer multiple perspectives or whatever, there is always the option of using a simpler config for live playing, but then turning everything when you render a performance, if you want to make a recording in a DAW. The only thing the performance of the system will affect is the amount of time it takes to perform the render. The recording will always be perfect, no matter what. (if it isn't, something's wrong)

Greg.

I don't follow this ...Plainly, higher drive performance can allow you to lower the instrument preload size (and make for a quicker startup).

But this is not related to audio buffer size reduction. That capability is purely a CPU and software issue. That is, a faster computer can effectively use a smaller audio buffer. A smaller buffer means more frequent refresh requests ... which can be satisfied by faster software, running on a faster CPU. But that refresh mostly comes from the preloaded cache.

But when a note has (nearly) exhausted the preload buffer, then a drive access is required. And if this happens when multiple notes are playing polyphonically, then multiple (and uncoordinated) drive accesses would be required. In this situation a slow drive might cause dropouts ... but not latency.

MacMacMac: You are taking the same overly simplistic view that I had, IMHO. There have been at least two reports that I'm aware of now (one from Macy - I forget who the other was) from users who were able to use a smaller audio buffer size, after switching from an HDD to an SSD. It may well be because they did in fact use a smaller pre-load with the SSD, and that might change the overall i/o pattern & interrupt frequency etc, in a way that allows a smaller audio buffer to be used without glitches.

Greg.

No, I did not use a smaller pre-load with the SSD.

The faster SSD with Ivory II American D allows me to use a smaller audio sample buffer (not talking about any pre-load buffer) and hence REDUCE THE LATENCY, or conversely use more voices with the same audio buffer size and same latency.

I did experiments and provided measurements with my results. I'm sorry, but MacMacMac's comments do NOT apply to my actual results. I don't mean to offend, but he provides that contrary information every time someone brings up latency. I think he writes based on how he believes these programs and virtual memory operating systems work. I wrote about my actual test and usage results.

I usually don't respond like this because I got tired of arguing about it a long time ago. It is what it is and I'm not interested in speculative arguments about how VST streaming in virtual memory operating systems systems work at a practical level in the latest computers and latest piano software (although I'm an engineer that does firmware, audio/MIDI software design, and digital hardware design). The results are clear in MY actual use.

For what it's worth, here is an excerpt from an earlier posting I did about using an SSD with Ivory II American D. I'm not trying to start an argument, nor do I want to participate in one. These are my results, take it for what it's worth.

---------

I previously ran Ivory II GP's standalone with a 128 sample buffer (44.1 kHz) and a 96 voice limit set on a 3.06 GHz Core 2 Duo iMac with the samples on a 7200 rpm Firewire 800 external disc drive. I never had "Slow Disk" messages, or the accompanying dropouts. When I added the Ivory II American Concert D, which includes a new version standalone app and AU Plug-ins, I started getting "Slow Disk" messages when the number of actual voices reached around 80 in number. It is very easy to generate 80 or more voices with this program. The samples are longer (5-8 secs in the program readout depending on the notes - the undamped top strings are the longest) on the American D than the previous Ivory II pianos, so more notes overlap even when released and there may be other differences in the newer version app as well. Bottom line, I had to increase my audio sample buffer [NOT a preload buffer] to 256 samples (or reduce the number of voices) to eliminate the "Slow Disk" messages and accompanying audio artifacts, neither of which I wanted to do. According to my Mac disk activity monitor the Firewire 800 HD was hitting about 30 MB/s (with 80 voices) when the "Slow Disk" messages appeared, but the maximum transfer rate of the Firewire 800 HD measured well over 80 MB/s (which is expected from FW 800 transfers). So I concluded the problem was not the FW800 transfer limit, but instead the random access time of the mechanical hard drive.

So I purchased a 256 GB SSD with an external FW800 (and USB 3) interface since the random access time of the SSD is negligible, approximately 0.1 mS. Once I moved the samples to the SSD it solved the issue entirely. I was able to run up over 250 voices according to the Ivory II readout (using the sustain pedal and pressing an unrealistic number of keys) before getting the "Slow Disk" message and artifacts using a 128 sample buffer. I bought the SSD with a USB 3 interface (which is about 5 times faster than FW800) - just in case the SSD limited by FW800 didn't solve the problem.

For my normal playing with the SSD I set the audio buffer to 64 samples (below that I could generate occasional ticks and pops from maxing out the CPU) and the maximum voices at 128. At 80-100 voices, which my normal playing generated, the transfer rate measured a maximum around 60 MB/s with no "Slow Disk" messages. The SSD still measured over 80 MB/s max due to Firewire 800, but Ivory II simply didn't need to go faster with my playing.

So I want to stress the original limitation was due to the random access time of the 7200 rpm disc (5400 rpm discs have even slower access times). That had limited the number of voices I could get with a 128 sample buffer and forced me to a 256 sample buffer. With the faster random access SSD, still using the same FW800 interface, I could reduce the buffer to 64 samples and increase the voices to 128 (that was an arbitrary choice over the max voices I needed and I'm not sure of the max number of voices I could have used with the 64 sample buffer, but I got over 250 voices with a 128 sample buffer).

All of this is very curious. I used to have an old, slow laptop ... 1.7 GHz Duo with a 7200 RPM drive. I had no dropouts, and decent but not stellar latency. Only when playing multiple pianos together (in chorus fashion) did I ever get dropouts. And all that on what is seen today as an archaic laptop, slow by any modern standard. They just don't make them that slow anymore. I wondered why people with better equipment were having problems?

I later switched to a much faster desktop, now four years old ... an i7-930 at 2.8 GHz ... but still with a 7200 RPM drive. I was able to reduce the audio buffer size to gain lower latency. And there are no dropouts ... unless I tie in all ten pre-loaded pianos. In that situation I get some dropouts. But it doesn't matter ... ten pianos playing at once is a ridiculous exercise.

In a production setting it would not be silly at all. Multiple instruments playing in concert would be the norm, so better gear would be needed. But this is not a production forum, so I was still stuck wondering why people were having problems with modern equipment.

Perhaps the answer lies here ...

Macy: You said you're able to get 250 voices with your SSD setup. Though I don't have figures, I have to think that this is akin to my ten-piano chorus mode ... which does give me problems with dropouts, likely because the disk drive cannot keep up. And this is in keeping with what I said earlier: "... when multiple notes are playing polyphonically, then multiple (and uncoordinated) drive accesses would be required. In this situation a slow drive might cause dropouts."

An SSD eliminates that disk contention. Which reads: If you go high with the polyphony, an SSD serves. Which implies: We're not in disagreement at all.

Question: Is your 250 voice situation a common one? Or is it just a benchmark/test? That is, do you run into such high polyphony in performance? I'm curious because mine seldom breaks 100.

Hmmm - now that is interesting.

Greg.

Fragmentation of the drives perhaps? In MacMacMac's case, perhaps he regularly defragmented his hard drive allowing for more continuous reads??? Perhaps the application is sensitive to fragmentation?

Where with an SSD, fragmented or not, because there are just so fast, fragmentation does not come into play.

Just a theory ...

Newbie question from somebody who doesn't use any sampled pianos anymore. (Only PT.)

What is the difference between buffer size and preload size? I always thought they were the same thing - not that I ever gave it much thought.