This forum is now locked and moved (back) to Plogue's forum http://plogue.com/phpBB3/viewforum.php?f=14
Memory Management in Sforzando
  • dtothewhdtothewh
    Posts: 2
    Hi,

     I have quick question about memory management in Sforzando, and what the Inst. Disk Pre Cacheing parameter does... 

    As I understand it, it should load the first 32kb of each sample into RAM, basically to compensate for disk access latency. Since I have loads of SSD drives I wondered if I could make this lower, and thus lower the amount that's loaded into RAM. However, I have a 410mb library in WAV format and when I load that in, the memory usage seems to shoot up as I play it - almost as if it's loading the samples I play fully into RAM, perhaps leaving the others only pre-cached.

    A quick comparison with another popular sampler revealed that the same 410mb patch yielded roughly 24mb of RAM used (operating at a 60kb cache), compared to the full 410mb in Sforzando. This is a massive difference - so I just wondered how the approaches differed?

    This is more a question driven from curiosity rather than than anything else :)
  • davidvdavidv
    Posts: 453

    There are a few things at work. some of it I can't disclose publicly on the internals of the engine. The minimum 32kb per file was a default settings in 2008 for low end machines, and it needs to be lowered indeed. you can experiment by editing GUI/gui_settings.xml



    <OptionMenu param="DID_STREAMING" x="195" y="102" w="60" h="18" alignment="center" color_back="#2A2A2AFF" color_border="#616161FF">
    <OptionItem name=" 32 Kb" value="32"/>
    <OptionItem name=" 64 Kb" value="64"/>
    <OptionItem name=" 96 Kb" value="96"/>
    <OptionItem name=" 128 Kb" value="128/>
    </OptionMenu>

    into

    <OptionMenu param="DID_STREAMING" x="195" y="102" w="60" h="18" alignment="center" color_back="#2A2A2AFF" color_border="#616161FF">
    <OptionItem name=" 8 Kb" value="8" />
    <OptionItem name=" 12 Kb" value="12"/>
    <OptionItem name=" 16 Kb" value="16"/>
    <OptionItem name=" 32 Kb" value="32"/>
    <OptionItem name=" 32 Kb" value="32"/>
    <OptionItem name=" 64 Kb" value="64"/>
    <OptionItem name=" 96 Kb" value="96"/>
    <OptionItem name=" 128 Kb" value="128/">
    </OptionMenu>


    However since the streaming engine is currently getting a streaming update for 16kb or less, the current shipping version is not meant for it, YMMV and we of course dont support this hack.




    There are other settings you could consider: Max Engine RAM Allocation: if you leave it at 512MB and play a 410MB patch, then at one point, sure its all going to eat that ram, and its by design. The idea is that pre-caching helps you play rapidly when you launch the file, and the streaming will stop at one point, making sure subsequent track runs at less likely of disk losses, say if the drives are busy streaming other things elsewhere or playing DAW audio.



  • dtothewhdtothewh
    Posts: 2
    Thanks David, very interesting... I appreciate the reply.

    So, if I understand correctly it would seem that Sforzando isn't actually *less* RAM efficient than others, just different in its approach - mostly in order to avoid staring at progress bars before you can play the patch itself? :)

    Seems to make good sense.

    Actually, I hope you don't mind but I had one other question: I was playing around with the same patch, both in WAV format and OGG format, and it seemed like loading it in compressed OGG format made no difference to RAM usage. Is this because a compressed format like OGG isn't a linear data stream, and must be converted in order to stream, and have loop points and so on? Are there any compressed formats that are linear that might provide both a diskspace and RAMspace saving, or is that an incongruous pipe dream?


  • pljonespljones
    Posts: 73
    I guess a "true streaming" engine could have a sample read component for any compressed format, reading in data on the fly and, so long as it was able to keep supplying blocks to the playback component fast enough not to skip buffers, it wouldn't have to retain more data in RAM than was needed to achieve that.

    However, I also guess getting too close to that approach might trigger patent lawyers...

    --edit--
    Hm.  Wouldn't work too well if you were dynamically adjusting offset/end points, though (you could cater for static offset/end easily enough, I think...).
  • davidvdavidv
    Posts: 453

    dtothewh : We could have implemented any streaming technique we wanted and do exactly what others do, but we wanted more flexibility. Some users even would PREFER everything being in RAM, cause they don't want to risk disk I/O conflicts with the DAW streaming audio and/or other streaming instruments from the competition clashing. Its a VERY LITTLE known fact that there is NO way for any plugin to know if OTHER plugins are using disks, ram, threads or any other computer ressources. With our method we allow BOTH, and its user configurable. Lower the Maximum RAM usage, and ARIA will NOT take more. but if you let ARIA cache more, it means less stuff will need to stream.


    pljones: I guess you are late to the party with regards to "true streaming" and patents:
    From the ARIA Player manual:
    "With the acquisition of Giga Technology, Garritan has also acquired exclusive rights to Conexant's Endless Wave Technology with the right to its hard-disc streaming and other cutting-edge technologies. Some of the Giga technologies are making their way into the ARIA Player."

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!