Harddrive Cache & Buffer speeds with DP?
Moderator: James Steele
Forum rules
This forum is for most discussion related to the use and optimization of Digital Performer [MacOS] and plug-ins as well as tips and techniques. It is NOT for troubleshooting technical issues, complaints, feature requests, or "Comparative DAW 101."
This forum is for most discussion related to the use and optimization of Digital Performer [MacOS] and plug-ins as well as tips and techniques. It is NOT for troubleshooting technical issues, complaints, feature requests, or "Comparative DAW 101."
Harddrive Cache & Buffer speeds with DP?
My family is on a tight budget so I have Snow Leopard now and I wanted to install it on my barracuda 7200.9 160GB harddrive. I am streaming all of my virtual instrument sounds from my second drive which is 500GB & 16MB buffer/cache speed. I'm also using Digital Performer 5.13 as well and I've heard rumors that it works with Snow Leopard fairly well. Will my virtual instruments such as Kontakt 3, Reaktor 5 & Ivory 1.7 work well with streaming if my main drive is 8MB Cache but my other is 16MB Cache? Is DP 5.13 mostly using RAM and no much of the cache rate in the hard-drive? Thanks.
Re: Harddrive Cache & Buffer speeds with DP?
You've asked a few simple questions requiring rather complex answers.
1. Sample library organization:
Not all libraries are created equal. Streaming a lot of VIs from a single hard drive can work well up to a point at which time there will be a moment where too much data is being searched and streamed at once. This can lead to data clog. The two solutions to this eventual issue (where dropouts in sample audio might occur) are to reduce the number of VIs and samples being used at once or to distribute your instruments onto two or more drives.
Like traffic-- one street (ie: hard drive and data path) can "handle" a lot of traffic (ie: data), but two streets make for more comfortable driving where the same amount of traffic is concerned.
2. Drive cache size vs performance:
Data stored on a hard drive is "paged" when the user loads a sample into a VI. The drive spins at a certain rate (7200 rpm or faster is the recommended standard) to find the data (seek time) and then it sends that data through the data buss to your RAM (transfer rate).
In the case of many VIs and where several are in use at once, only a PORTION of the samples to be streamed are loaded into RAM. Other data references are loaded into Virtual Memory which is a sector of your system drive. Virtual Memory stays very busy keeping up with all the data, paging that data in an out of RAM as your project grows and edits are made.
Because of the size of samples being used these days can be very large, quite often hard drive caches of 8MB or 16MB are not large enough to beneficially manage all the "paged" data, so hard drive caches in general are ignored and the data is sent directly to RAM and Virtual Memory. Some sample libraries on certain projects can page 100MB or more of reference data. To take better advantage of a hard drive's cache, this would be another reason for splitting your instruments across several drives to keep the amount of streaming data a bit lower per drive, allowing your hard drives to not work so hard.
Having 4 GB of RAM or more would yield more noticeable benefits than the size of the hard drive cache. That is not to say that under the right circumstances the hard drive cache won't help. It just might help where data being used can be measured in MB and not GB.
I've not tested drives with 32MB caches, but I have spoken to a few VI developers who don't feel that the hard drive cache is high on the list of critical issues to address where performance is concerned if the paged data exceeds the drive cache limit anyway.
If you're running Snow Leopard, then you have a powerful CPU (Core Duo or better). This is not the problem here.
On one's system drive, OSX might take better advantage of hard drive caches because the data being paged from that drive could be a whole lot smaller than a body of samples being paged from other drives containing instrument libraries.
Still, having 4GB or more of REAL memory (RAM) allows Virtual Memory to have an easier time. This and distributing your streaming data across different drives and/or along different data paths will be MUCH more helpful than the drive cache size.
I don't think you'll notice a significant difference (if any) in drive performance where the spin times are both 7200 rpm, regardless of cache size.
If your machine is a pre-2008 model, the firewire buss is only 33Mhz. The new machines have firewire busses running 2.6+Ghz (much better performance). So just take care if you are using a single drive on the older slower buss. Data buss clog can happen easily in such cases.
Without any certainty of the type of machine you have, those with MacPro towers have more options for storage and data shuttling with 3 open bays for internal SATA as well as third-party expansion options for eSATA configurations.
MacBook Pro users have a few options if the card slot is used. Cards for these slots can offer an independent buss, allowing for additional drives or other devices to used effectively in conjunction with the built-in firewire buss.
MacBook users don't have the card buss option and run into the same hurdles as MacMini or even iMac users run into, which is a limit of buss options, making it difficult to connect a lot of additional hard drives.
For the most pragmatic usage of a DAW on a limited budget, it's important to know the threshold of pain for your computer. Here is one of my stress tests:
1. Load 10 instances of various VIs into DP.
2. Load a healthy amount of sounds into each instance, making sure not to duplicate anything. If you loaded some violins, proceed to load violas and cellos into the next available slot. Keep going with percussion, guitars, pianos, keyboards, basses, effects, and so on. If using Kontakt, make use of all 16 MIDI channels in each instance, loading different samples into each MIDI channel. If you are using 10 instances of Kontakt, you'll have 160 available MIDI channels to load with samples. Continue until all available MIDI channels are full or until your computer complains.
3. Start loading in some MIDI note data. It doesn't really matter what it is, and you don't even have to get that creative. Play in about 4 measures of anything at all into one track. Copy/paste that note data into the rest of your tracks.
4. Hit play. If DP runs smoothly, add one more VI at a time until the computer complains. If DP chokes right out of the gate, delete one VI instance at a time until the computer runs smoothly. The amount of data you have loaded which allows DP to run smoothly will be the machine's threshold of pain.
5. If you expect to run lots of audio tracks and effects, you'll want to reduce the number of VI instances by at least 25% +/-, depending upon the number of audio tracks you expect to use. Of course, most people won't use all available MIDI channels on all VIs, so reducing the number of samples per instance will also improve performance and open up additional resources for real world usage.
Just know your machine's limits and work within those limits until such time you are ready to expand memory or storage further.
1. Sample library organization:
Not all libraries are created equal. Streaming a lot of VIs from a single hard drive can work well up to a point at which time there will be a moment where too much data is being searched and streamed at once. This can lead to data clog. The two solutions to this eventual issue (where dropouts in sample audio might occur) are to reduce the number of VIs and samples being used at once or to distribute your instruments onto two or more drives.
Like traffic-- one street (ie: hard drive and data path) can "handle" a lot of traffic (ie: data), but two streets make for more comfortable driving where the same amount of traffic is concerned.
2. Drive cache size vs performance:
Data stored on a hard drive is "paged" when the user loads a sample into a VI. The drive spins at a certain rate (7200 rpm or faster is the recommended standard) to find the data (seek time) and then it sends that data through the data buss to your RAM (transfer rate).
In the case of many VIs and where several are in use at once, only a PORTION of the samples to be streamed are loaded into RAM. Other data references are loaded into Virtual Memory which is a sector of your system drive. Virtual Memory stays very busy keeping up with all the data, paging that data in an out of RAM as your project grows and edits are made.
Because of the size of samples being used these days can be very large, quite often hard drive caches of 8MB or 16MB are not large enough to beneficially manage all the "paged" data, so hard drive caches in general are ignored and the data is sent directly to RAM and Virtual Memory. Some sample libraries on certain projects can page 100MB or more of reference data. To take better advantage of a hard drive's cache, this would be another reason for splitting your instruments across several drives to keep the amount of streaming data a bit lower per drive, allowing your hard drives to not work so hard.
Having 4 GB of RAM or more would yield more noticeable benefits than the size of the hard drive cache. That is not to say that under the right circumstances the hard drive cache won't help. It just might help where data being used can be measured in MB and not GB.
I've not tested drives with 32MB caches, but I have spoken to a few VI developers who don't feel that the hard drive cache is high on the list of critical issues to address where performance is concerned if the paged data exceeds the drive cache limit anyway.
If you're running Snow Leopard, then you have a powerful CPU (Core Duo or better). This is not the problem here.
On one's system drive, OSX might take better advantage of hard drive caches because the data being paged from that drive could be a whole lot smaller than a body of samples being paged from other drives containing instrument libraries.
Still, having 4GB or more of REAL memory (RAM) allows Virtual Memory to have an easier time. This and distributing your streaming data across different drives and/or along different data paths will be MUCH more helpful than the drive cache size.
I don't think you'll notice a significant difference (if any) in drive performance where the spin times are both 7200 rpm, regardless of cache size.
If your machine is a pre-2008 model, the firewire buss is only 33Mhz. The new machines have firewire busses running 2.6+Ghz (much better performance). So just take care if you are using a single drive on the older slower buss. Data buss clog can happen easily in such cases.
Without any certainty of the type of machine you have, those with MacPro towers have more options for storage and data shuttling with 3 open bays for internal SATA as well as third-party expansion options for eSATA configurations.
MacBook Pro users have a few options if the card slot is used. Cards for these slots can offer an independent buss, allowing for additional drives or other devices to used effectively in conjunction with the built-in firewire buss.
MacBook users don't have the card buss option and run into the same hurdles as MacMini or even iMac users run into, which is a limit of buss options, making it difficult to connect a lot of additional hard drives.
For the most pragmatic usage of a DAW on a limited budget, it's important to know the threshold of pain for your computer. Here is one of my stress tests:
1. Load 10 instances of various VIs into DP.
2. Load a healthy amount of sounds into each instance, making sure not to duplicate anything. If you loaded some violins, proceed to load violas and cellos into the next available slot. Keep going with percussion, guitars, pianos, keyboards, basses, effects, and so on. If using Kontakt, make use of all 16 MIDI channels in each instance, loading different samples into each MIDI channel. If you are using 10 instances of Kontakt, you'll have 160 available MIDI channels to load with samples. Continue until all available MIDI channels are full or until your computer complains.
3. Start loading in some MIDI note data. It doesn't really matter what it is, and you don't even have to get that creative. Play in about 4 measures of anything at all into one track. Copy/paste that note data into the rest of your tracks.
4. Hit play. If DP runs smoothly, add one more VI at a time until the computer complains. If DP chokes right out of the gate, delete one VI instance at a time until the computer runs smoothly. The amount of data you have loaded which allows DP to run smoothly will be the machine's threshold of pain.
5. If you expect to run lots of audio tracks and effects, you'll want to reduce the number of VI instances by at least 25% +/-, depending upon the number of audio tracks you expect to use. Of course, most people won't use all available MIDI channels on all VIs, so reducing the number of samples per instance will also improve performance and open up additional resources for real world usage.
Just know your machine's limits and work within those limits until such time you are ready to expand memory or storage further.
6,1 MacPro, 96GB RAM, macOS Monterey 12.7.6, DP 11.33
Re: Harddrive Cache & Buffer speeds with DP?
Hey Thanks Frodo!! This gives me some peace of mind about not having to spend much money right now. RAM is cheap so if that is the most noticeable difference then that will be my goal to get. Thank you for the detailed info. I now know more about Cache and Buffer speed issues with hard drives. 
Digital Performer 7.22 | Macbook Pro i5 | Focusrite Saffire Pro 14