When a streaming sound becomes virtual, it stops requesting I/O transfers. In "From Beginning" mode, all its I/O buffers are flushed and the Stream Manager is able to use them for other sounds. This is also generally true for "From Elapsed Time" mode. In "Resume" mode though, the sound might hold an I/O buffer, but all the others are, and no more I/O data is requested.
When the voice becomes physical again, I/O streaming resumes. Seeking is required for "From Beginning" and "From Elapsed Time" modes. Some time is given for the streaming sound to pre-buffer enough before restarting playback. No source starvation notifications will be issued. This is similar to simply starting a streaming sound: there is some inherent latency due to streaming which is not considered as starvation. Source starvation notifications only occur after playback has started.
When a sound starts and it is already below volume threshold, it becomes virtual right away. However, in order to process "Resume" and "From Elapsed Time" behaviors correctly, the file header must be read from disk and parsed. So there is some I/O going on at the beginning. In "From Beginning" mode, the sound engine waits until the sound is audible before attempting to read its file header.
Continuous (random or sequence) containers start sounds back to back. Thus, a silent continuous container with "From Elapsed Time" virtual behavior will "virtually" wait until the current sound stops playing, and then it will launch the next sound which will also be virtual, and so on. Every time a new sound is launched, its header is fetched from disk since its behavior is "From Elapsed Time".
