Vienna Symphonic Library Forum
Forum Statistics

199,020 users have contributed to 43,150 threads and 258,876 posts.

In the past 24 hours, we have 7 new thread(s), 15 new post(s) and 58 new user(s).

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries
  4. 1st-time Dropouts and Clicks

  • 1st-time Dropouts and Clicks

    J
    J
    Hey there!

    I know this is an old issue, but I was wondering if anyone ever figured out how *not* to have any sample dropouts/clicks when playing a VI sample for the first time.

    I installed Vienna Ensemble and hoped it would fix the issue but it still doesn't. Right after loading the software and playing a sample, it drops out or clicks. I have to basically play a full scale up and down to make sure it will not happen again. Then it plays fine (at least for many hours).

    This subject was discussed at length last June/July I believe. I was just wondering if a fix had been found since then.

    Thanks!
    Jerome
  • cmC
    VSL Team
    cmC
    last edited
    last edited

    you should add this applies to the OS X versions ... though i've noticed lately this applies also to some setups with XP64 and VISTA64 if the pagefile size is set to auto or not a small value (< 512 MB)

    basically the preloaded sample data should stay in physical memory ("wired") because it doesn't make sense to load them from disk into memory, then page them out to virtual memory and finally reload them again if accessed by the application.

    unfortunately there seems to be no option to force such a behaviour, only to tell the OS allocation of wired memory would be preferred.

    Wired memory (also called resident memory) stores kernel code and data structures that should never be paged out to disk. Applications, frameworks, and other user-level software cannot allocate wired memory.

    see the full article here: http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html

    i've already posted earlier that i am - to say the least - not happy with the fact one cannot set the location for the pagefile in OS X (in fact and with some knowledge you can, but it is not supported), otherwise we could direct the pagefile to a RAM-disk which is almost as fast as the memory (if drivers for OS X would exist), i've tried this with a windows 2003 server (4GB RAM + 4 GB RAM-disk for the pagefile) and the result has been astounding increase of performance.

    NOTE: this is not mac-bashing and such a behaviour is generally good practice for running an average application

    christian

    and remember: only a CRAY can run an endless loop in just three seconds.
  • J
    J
    Thanks for the informative answer, cm. Does this mean that this problem simply can't be solved at this time? What about the fact that - to my knowledge - this doesn't happen on *all* Mac configurations? Thanks! J.
  • cmC
    VSL Team
    cmC

    your observation is presumably related to:

    As an application uses up space, the virtual memory system allocates additional swap file space on the root file system. and

    When the number of pages on the free list falls below a threshold (determined by the size of physical memory), the pager attempts to balance the queues.

    this means depending on the number of applications running, the available physical memory, the memory allocated per aplication and in total causes the pager to act or not beyond a *certain* (which?) threshold - so actually the same system might behave different in a different situation.

     

    an idea which comes into my mind would be to *touch* every loaded sample (in analogy to the giga load time optimizer) to tell the system the file *is in use* and therefore needed to be kept in resident memory ... but if this would be even possible is pure speculation and would for sure increase loading times ...

     

    however the issue is known and if our programmers find a straight forward method to overcome this inconvenience we will see it implemented.

    related to the same background is the question: why can the application not calculate how much memory in fact will be available before loading a new patch if actually the needed memory is known.

     

    not too satisfactory and tightened by the footnote These measurements will change with each new Mac OS X release. They are provided here to give you a rough estimate of the relative cost of system resource usage.

     

     i smell this will give us more trouble and headache as the amount of installed memory increases further, also on windows 64bit systems ....

    christian

    and remember: only a CRAY can run an endless loop in just three seconds.
  • J
    J
    It seems to me that this is related to the idea that the more RAM you have, the better shape you're in... meaning that the problem would happen less if there was much more "available physical memory".

    So, potentially, more problem will happen if you have 2GB of memory and use 1.6GB for samples, than if you have 4GB and only use half of it...

    J.