Vienna Symphonic Library Forum
Forum Statistics

183,687 users have contributed to 42,312 threads and 255,136 posts.

In the past 24 hours, we have 2 new thread(s), 13 new post(s) and 53 new user(s).

  • as far as I know the memory buffer isn't modifiable with play instruments. You can however load the entire instrument into ram, but this is impractical because a patch that takes 1GB of ram to stream would cost 12GB if you loaded it entirely into RAM. Its something ridiculous like that. Although you can try, I wouldn't dare do a PLAY instrument on a 5400. I know VSL will at least work on a 5400 external drive, since I tried that once. Not going to guarantee that you can get many instruments running but i know it works.

  • HÃ¥kan,

    A while ago, I made a (theoretical) burst performance analysis of a couple of harddrives. I now added the Caviar Green as well. As you can see from the table, SSDs are clearly superior to regular drives. The Caviar Green doesn't stand up very well in this competition. Even though regular drives can stream a reasonable amount of voices when triggered sequentially (such as dragging your forearm on the piano), they are terrible at pure burst performance, triggering many notes at once. Quantized music would be the hardest task for a mechanical drive.

    Many new libraries, such as Dimension Strings or Hollywood Strings, trigger many voices (players, microphones etc) exactly at the same time. Then the burst values from this table are most important.


  • Thanks a lot Martin, very informative! Such a huge difference between mechanical and SSD! [:O] The Caviar eco-drive, on the other hand, is not far from the Caviar Black. Luckily, when doing orchestral stuff, I hardly quantize at all.


  • The 7200rpm drive is about 25% faster than the 5400rpm drive. 25 notes burst performance at 16384 (default) buffer size is not much however. One keypress of a Dimension strings patch with 8 violins and 4 layers velocity xfade gives 32 voices...


  • Martin, next time you do tests if would be useful to do some at much lower buffers. I've never gone as high as 1024. Mostly I work at 128 and bump it up to 512 for mixing, but it is the 128 that is most important, because that's as high as I want to go for playing live.

    DG


  • DG,

    the chart does not refer to soundcard buffers - they are precache buffers as set in VIPro directory manager.


  •  I think the values are no audio buffers, these are the preload buffer sizes you can setup in VI PRO.

    Default size is 16384, and I don't recomment to go below 2048. My usual buffer size working with SSDs is 4096 which enables me to load more than 1.000.000 samples into RAM on my system.

    best

    Herb

    edit: I see Martin was faster with his reply.


  • last edited
    last edited

    @MS said:

    DG,

    the chart does not refer to soundcard buffers - they are precache buffers as set in VIPro directory manager.

    Ah, I see. OK move along then. Nothing to see here. [;)]

    DG


  • last edited
    last edited

    @herb said:

     I think the values are no audio buffers, these are the preload buffer sizes you can setup in VI PRO.

    Default size is 16384, and I don't recomment to go below 2048. My usual buffer size working with SSDs is 4096 which enables me to load more than 1.000.000 samples into RAM on my system.

    best

    Herb

    edit: I see Martin was faster with his reply.

    Yeah, you need to up your "fast on the draw" skills, Herb.  [:D]

    DG


  • Another related issue. PLAY engine will start having dropouts and acting wonky, yet it didnt crash VEP immediately. Have to reload template to solve this. After this had happened, VEP crashed on exit. Leads me to believe that this could be a related issue. here's the link to my post on EWQL forums. http://www.soundsonline-forums.com/showthread.php?p=715624#post715624

  • [quote=MS]

    HÃ¥kan,

    A while ago, I made a (theoretical) burst performance analysis of a couple of harddrives. I now added the Caviar Green as well. As you can see from the table, SSDs are clearly superior to regular drives. The Caviar Green doesn't stand up very well in this competition. Even though regular drives can stream a reasonable amount of voices when triggered sequentially (such as dragging your forearm on the piano), they are terrible at pure burst performance, triggering many notes at once. Quantized music would be the hardest task for a mechanical drive.

    Many new libraries, such as Dimension Strings or Hollywood Strings, trigger many voices (players, microphones etc) exactly at the same time. Then the burst values from this table are most important.

    There seems to be something wrong with the WD Cavier Black's in this test, the 2TB Cavier Black's I use are 64MB cache/4.2mS access time/126MBps transfer rate, the above test figures don't seem to reflect reality.

    I have ran extreme tests with Dimension strings (achieving 1024 voices playing - helped along by using a longer than normal release time to keep all the voices going)   - using the default buffer size.  I still don't see the need for expensive and inadequate capacity SSD drives. 

     The specs may try to show one thing,  but reallity seems to be something completely different.  Are people just fooling themselves with unachievable  SSD specs?


  • andyjh,

    1. You are not considering rotational latency. The average access time is just as described in the table, you can confirm this by googling around a bit, reading some in-depth reviews of said drives.

    2. Regarding playing 1024 voices - the table states a maximum, non-cached performance of 635 stereo voices. Dimension Strings is using mono voices, so maximum theoretical voice count would be twice, 1270.

    3. Your drive and operating system is caching data, so by playing the same data over and over again, it will be accessed from cache, and the burst figures become less relevant.

    4. As soon as you trigger a set of voices/waves that are not in cache, in other words notes you have not played before, the burst figures become relevant. This would also apply to an arrangement you open up directly after a reboot of the system, when caches are not yet populated.