Proper realtime processing of multiple streams requires that only the NEXT block of EACH stream be read before attempting ANY of the following blocks. This makes multi-streaming much more like random access, but can force consistent worst case head travel times on HDDs, such as where streams are on separate sections of a drive, as for different mic positions for orchestral samples.
Also, in situations like above, NCQ might actually work against low-latency, because it will tend to reorder the requests to get the sequential blocks after each other, THEN get another close bunch.
