\'Answers\' on Halion and EXS streaming samples...
I\'ve now received \'answers\' from both Emagic and Steinberg as to whether Halion and the EXS24 will stream samples from hard disk.
Apart from saying that they WILL stream from hard disk, neither company seems willing to comment much on performance.
1. Will the EXS24 sampler have real time hard disk streaming like the Nemesys Gigastudio? I hear conflicting reports.
2. If so, what will the maximum polyphony count be on a \'recommended\'system.
3. If so, what will the latency be on a recommended system?
Steinberg\'s answer re - Halion:
Halion will be able to stream large samples from disc.
\"Guestimated polyphony\" has not been established yet and there are many factors affecting what is considered to be a \"recommended\" system.
The plugin itself has very little to do with the system latency settings.
Latency in a VST system is determined by the quality of ASIO driver supplied with your audio hardware, amount of RAM in your system and the CPU speed.
Emagic\'s response re - EXS24
Yes the EXS 24 will have an option to stream from disc in the next sub release. The next two questions are dependant on the system and software in question. I will not be able to answer these properly until a version is
available. Having said that, polyphony will only increase on the current specs and latency is dependant on your I/O device.- currently as low as 6 ms with ASIO 2 drivers.
I still can\'t see how they can do this working as well as Gigastudio as a plugin when Nemsys have to jump through hoops to get
\'real time\' latency at kernel level. Even the B4 and Pro52 feel sluggish when I run them as stand-alones on my system. As plugins I think they\'d be unplayable, and they\'re certainly not as demanding as 160 streams of interpolated and filtered hard disk samples.
Re: \'Answers\' on Halion and EXS streaming samples...
For what its worth, here are my thoughts on the subject of plug-in streaming samplers.
In broad terms, there are basically two time-critical issues.
1) Playing out the sound buffers via the sound card
2) Reading the sound buffers in from the hard drive
and of course, also the issues involved in getting these two working correctly together.
Because Nemesys wants to squeeze the utmost performance out of the computer, real-time scheduling techniques are used to get 1 and 2 to work in tandem.
OK, well, what are the trade-offs? In simple terms, timing problems on 1 will affect the playback latency. If it is not possible to have real-time timing on this, timing restrictions on 2 can be reduced while still keeping latency manageable.
Timing problems on 2 will cause latency, clicking and polyphony issues.
So basically, on a non-realtime system, to keep latency manageable, much larger buffers would have to be read in from the harddrive. In this fashion, it is not critical if a scheduled read happens a bit late, the system has buffered enough of the sample in RAM to continue playing.
And by pre-buffering enough of the sample in advance, it will play at lowest latency from the plug-in, while not requiring absolutely immediate harddrive access.
As I recall, EndlessWave pre-buffers 64Kb of each sample, which it then uses to play back the sample as soon as the key is struck. Slices of 64Kb are then read for each sample being played back (this is why it is the random block read rate of the drive that is important, not the sustained throughput).
Obviously, because the buffer is so small, each read operation has to happen absolutely on time.
If you cannot ensure such timing accuraccy, you have to increase the buffering, otherwise you will click. This happens to be the reason why VCACHE settings will improve performance on some systems (it effectively tries to pre-buffer more data).
So a plug-in will have to buffer significantly more of a sample in memory.
Obviously, this makes the sampler much more dependent on RAM. Think in terms of Nemesys\' \"instrument slot\" concept. For every single sample you want to stream from the disk, you have to allocate a pre-buffer slot. On pianos, e.g. this may be a sample for every note (for every velocity layer, pedal up, pedal down).
So, while one may be able to obtain similar latencies and even polyphony with a plug-in sampler, you will not be able to have the same number of instruments loaded at the same time (so multitimbrality will decrease), or you will have to use instruments with fewer samples (i.e. velocity layers, etc.)
Also, because you will need to pre-buffer so much more, it will take significantly longer to load instruments, than with Giga.
By the way the above companies are phrasing their responses, I would guess that these plug-ins will do the following:
Load most of the samples possible entirely into RAM. Only the *larger* samples will be streamed from harddrive. So you will maybe have 80% of your samples fully loaded into RAM, with 512Kb (or whatever) blocks of the larger samples, with new blocks read in as necessary.
The point is that because such a scheme *needs* to use more buffer memory for each slot, I doubt sincerely whether you will be able to load the detailed level of performances you can with Giga. Except if you use vastly more RAM.
And then also, pre-buffering more of a sample has implications for the polyphony.
When comparing Giga to plug-in solutions, it is thus necessary to bear in mind not only
d) number of simultaneously loadable samples
e) sample load time.
[This message has been edited by cc (edited 05-25-2001).]
Re: \'Answers\' on Halion and EXS streaming samples...
Simon, you\'re right.
I finally connected the B4 via Asio and its latency is fabulous - rock solid, fast reponse reminiscent of my (better) hardware components. I just had to raise the Pulsar ULLI to the second lowest position in order to remove the clicking.
Problem is, I don\'t really understand the whole ASIO/Pulsar routing thing. I know midi realy well, but when it comes to routing audio inside the PC I\'m a major newbie.
Next step is to see how I can run a couple of stand alones - B4 & Pro52 - simultaneously. Right now I\'m being told the hardware\'s unavailable when I load the second stand alone.