Vienna Symphonic Library Forum
Forum Statistics

196,468 users have contributed to 43,018 threads and 258,412 posts.

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

  1. Home
  2. General & Hardware
  3. Query on iLok decryption CPU-burden in realtime streaming [Edit].
  • BenB
    VSL Team
    BenB

    Sorry, I thought that my explainations have already answered this question. Let me try again:

    @Helmholtz said:
    In all of VSL's iLok libraries, all sample audio is PACE(iLok)-encrypted prior to download and installation.

    Our samples contain copy-protection.

    @Helmholtz said:
    A fresh or moved installation of a VSL iLok library does not finally decrypt the sample audio.

    Our samples are downloaded and installed on your drive.

    @Helmholtz said:
    Decryption of a sample takes place only as and when that sample is required for realtime audio processing and streaming as a component of one or more patches engaged by the user's playing or programming.

    Whatever we do, as you can hear, the Synchron Player outputs audio data your DAW can use 😊

    @Helmholtz said:
    Encrypted sample audio is first fetched from RAM as and when required for realtime streaming - given that the (user-adjustable) RAM-Preload size is big enough to include all of the samples currently made available in the Player for realtime streaming; otherwise it is fetched from storage into RAM - and then it is decrypted and processed according to the active Synchron Mix Channel inserts, routing, etc settings for each patch being streamed in realtime.

    Again, your DAW gets usable audio data. We / I can't confirm or deny anything else regarding this topic.

    @Helmholtz said:
    Compared to the above, in the case of VSL's E-Licenser libraries, either no decryption takes place as a normal part of realtime sample fetching, mix-processing and streaming, or else only a trivial amount of such decryption takes place and is much faster.

    Neither is true.

    @Helmholtz said:
    If my assumptions above are substantially valid, I'm asking if VSL can envisage, at some future time, moving the weightiest part or all of sample decryption into either

    the Install function, or
    the Preload function.

    Answer: No.
    Reason: Whatever we do or not do, there is no significant difference in performance in regards of streaming and real-time performance.
    In case you experience streaming issues it might be caused by your hardware / setup, configuration, or a bug in our software. In this case please contact our support via mail. Right now I'm not aware of any such bug/issue.

    Ben@VSL | IT & Product Specialist
  • HelmholtzH
    HelmholtzH
    last edited
    last edited

    Ben, thanks again.

    I don't believe I'm dealing with any sort of bug or bugs. I do believe my Player software, DAW & computer hardware and software are operating as designed and intended.

    I'm simply expressing thoughts and ideas as a user to other users as well as to VSL.

    Now I must sign off for the day - it's getting very late here.
  • ravezR
    ravezR
    @Ben said:
    @ravez said:

    I wonder why if the synchron player is inside audiogridder, switching from one track to another becomes instantaneous again.




    I guess the decryption happens only at the first load in this case?


    I guess the app does not close the UI and instead preserves it in RAM. Most DAWs and VEP will unload the UI to preserve RAM instead.

    I see, I just wish i could switch tracks with the Synchron player GUI open without waiting 1-2 seconds for it to re-draw, just like when wrapped in Audiogridder or like any other player (Opus, Kontakt, Sine, Spitfire etc).

    wonder what the ram difference actually is to justify such performance lag, is this really how the player is designed to work?

    made a video to show the issue
  • BenB
    VSL Team
    BenB
    @ravez said:
    wonder what the ram difference actually is to justify such performance lag, is this really how the player is designed to work?

    * your DAW designed to work

    And yes, the additional RAM usage is noticeable, especially with many instances.

    Ben@VSL | IT & Product Specialist
  • stephen limbaughS
    stephen limbaughS

    Ben do you recommend using as much RAM as is available in the Synchron Player? So if I have a template that uses 52Gb, but have 128gb total, then setting the Synchron Player to use more RAM will increase performance in a noticeable way?
  • BenB
    VSL Team
    BenB
    @stephen-limbaugh said:

    Ben do you recommend using as much RAM as is available in the Synchron Player? So if I have a template that uses 52Gb, but have 128gb total, then setting the Synchron Player to use more RAM will increase performance in a noticeable way?

    Yes, it might increase performance, especially CPU load if it is already working hard. If your CPU has not much to do you will not notice a difference.
    Still, the downside will be more RAM consumption and significantly longer sample loading times.

    Ben@VSL | IT & Product Specialist
  • HelmholtzH
    HelmholtzH
    last edited
    last edited

    Here's what the Synchron Player's speed test reported back in the pre-iLok days when Synchron Strings was released; this screen shot is still included in the current Synchron Player User Guide. I defy anyone to match these results now for an iLok Synchron library (especially the amazing ratio between 64k and 4k results):-

    However if, as Ben noted above, the Preload software has been substantially revised since then, it's probably not sensible to try to make any meaningful deductions about the then-vs-now difference in terms of the burden added by iLok. So I won't.
  • HelmholtzH
    HelmholtzH
    last edited
    last edited

    I've found that manually adding to Preload Size in the Database does nothing significant in terms of relieving CPU workload on playback.

    My total RAM use is well within my machine's maximum (64GB).

    In my Synchron orchestra stress tests, the iMac's Activity Monitor shows no noticeable fetching of samples from storage during playback, either with or without my additions to Preload Size.

    Of course the hugely critical factor in CPU streaming workload is how many mix channels are switched on in the Synchron Players. To get an idea of how well or badly my system performs under various conditions, I've been experimenting with a Synchron basic symphony orchestra under various different levels of stress. This test build in Logic doesn't use VEP; there are no plugin Fx running in the Synchron Players or in Logic; and just 2 stereo audio routes between each Synchron Player and Logic.

    Stress testing the whole of this basic orchestra (27 Synchron Players) consists of running a looped 1 Bar chromatic scale of nearly 2 octaves for every Synchron Player, every note a 1/16, played as fast legato at various different BPMs and with various numbers of Synchron Player mix channels switched on.

    At my fastest sensible tempo of 110 BPM and with only 1 mix channel switched on in all players, I get this:-

    With 4 mix channels switched on in all players, at the same tempo, this:-

    No audio plop-outs and no CPU crunch-outs anywhere.

    Not too shabby for a 2017 iMac 7700K - helped along by recent addition of a couple of very fast Samsung SSDs via Thunderbolt 3.
  • stephen limbaughS
    stephen limbaughS
    last edited
    last edited

    I'm back-and-forth with VSL support helping me on some performance issues, but booting things up this morning and changing my Synchron Player preload size from 3072 to 8-thousand-whatever caused the Synchron+VEPro tab CPU meters to drop by ~50% literally.

    In fact, using VEPro, that problem session from the other thread (the locked one) now operates perfectly EXCEPT for the single-core Logic Pro thing when it's a buffer of <256 and a recording track is highlighted during a tutti passage.

    Anything at 256 buffer and above, a highlighted track remains playable live without pops.

    For reference, this is a tutti passage with Synchron Series instruments with 5+ microphone positions enabled, some VI series instruments in MIRpro 3D, totaling ~54 tracks with various FX plugins engaged. Machine is an M3 Max.
  • HelmholtzH
    HelmholtzH
    last edited
    last edited

    Stephen, very glad to hear you're now back in business with your new MBP. That's great news!

    It seems to me your 128GB RAM allows your system to cache a much larger amount of sample files in RAM during Preload, now that you've whacked your Preload Sizes up to 8192.

    When I reboot my system then launch my Synchron Orchestra Stress Test in Logic, I can see VSL's Preload cache files building up until they're using the maximum that my 64GB system RAM has to spare for caching - which turns out to be only just about sufficient for my test orchestra. And that's probably why, if I increase my test orchestra's Preload Sizes to 8192 then reboot and relaunch, I'm not seeing any increase in cache size, nor any reduction in CPU load. My maxed-out 64GB RAM just ain't big enough for any of that good stuff.

    I'm going to experiment further, e.g. adding VEPro, and using patch changes during my test runs, so that I have some sort of benchmark with which I can check for the performance impact of using various different libraries, of software updates, and of various different configurations and automation. I just wish I'd set up a benchmark test like this before all the iLok and Apple Silicon upheaval took place.
  • BenB
    VSL Team
    BenB

    You will only see performce improvements if your CPU is the bottleneck and running at full load during playback.

    It will also depend on the drive. The slower the drive, the larger the noticable performance gain. Also you will notice them more with SATA drives compared to NVMe drives. It also hugely depends on the library and how you use it.

    A preload buffer size of 8192 will load exactly the same amount of data into RAM on a 128GB RAM system as on a 64 GB system.

    If you don't have any performance issues, then measuring/tweaking these settings is a waste of your time/life.

    Ben@VSL | IT & Product Specialist
  • HelmholtzH
    HelmholtzH

    Thanks Ben. Interesting perspective.

    Aren't many if not most users apt to tweak or 'fettle' their systems now and then, always looking for improvements? I'm certainly one of those.
  • BenB
    VSL Team
    BenB

    No, most users simply want stuff to work and don't bother with these things at all unless something doesn't work as expected.

    I guess @stephen limbaughalso started to look into it because he ran into a CPU bottleneck, and not because he loves tweaking system and sample player settings just for fun (@stephen limbaugh feel free to correct me if I'm wrong).

    I also had looked into this topic years ago when my mid-class CPU could not keep up with my projects (clicks and drop-outs) and I did not had the budget to get a better one, I was able to get 30-40% more performance out of it by tweaking Bios, optimizing Overclocking settings, increasing preload buffer size, moving multi-mic libraries to my fastest SSDs, etc.
    Right now I don't bother as I'm currently not running into issues and optimizing now would get me an increase in performance of exactly 0%.

    Ben@VSL | IT & Product Specialist
  • HelmholtzH
    HelmholtzH
    last edited
    last edited
    This post is deleted!
  • stephen limbaughS
    stephen limbaughS

    @Ben haha... no I definitely couldn't give a damn about computer efficiency, I just want the thing to play back at low buffers 😅.

    I should also note that VSL support has zeroed in on an issue concerning the folder system of my drives. Crashes are happening because the system was scanning for the samples and getting hangs.

    Also, since removing the additional folder on the external drive, the read speeds in the Synchron Player are now measuring 556.2MB/s, an increase from 443.2MB/s.
  • HelmholtzH
    HelmholtzH
    last edited
    last edited

    Two kinds of computer system 'fettlers': those who love to fiddle around in very techie areas such as BIOS or the guts of the OS; and those - including me - who can't be arsed to wade into the deadly boring geeky detail (which is why I've always bought Apple), but who nevertheless like to know what it is we're dealing with and what can and can't be done with it.

    These days personal computing is nowhere near as straightforward as it was back in '77 when I first got into microcomputing. But no matter that computer and software companies nowadays are ever more determined to make customers believe they shouldn't worry their pretty little heads about what goes on under the hood, I'll never be the ideal consumer type. Lol.

    "OLD, NOT OBSOLETE" ~ me, imitating a famous Austrian Terminator, describing my ancient iMac. (2017 is really ancient, right?).

    I've pushed my stress-test Synchron orchestra harder, adding a Synchron D-274 track for live use. Now I can use an I/O Buffer Size as small as 32 samples, along with Medium Process Buffer Range, with all Synchron instruments playing back on just 1 audio Mix Channel each, while playing the D-274 live. (I'm not a pianist but that doesn't mean I can't knock out plenty of 2-handed chords at speed.)

    The result:- live piano latency is nice and short, AND with at least the bare bones of full orchestral accompaniment. Of course it's not as full-on as you're now getting with your M3 MBP, Stephen. But what it means for me is that I won't be contributing to Apple's revenue as early as I'd previously thought.

    Here's the evidence (One mix channel switched on in each Synchron player):-

    Strange thing now is - I'm getting less total RAM pressure than previously, even though in both cases I rebooted immediately before taking readings once the whole orchestra had fully completed its preloads. Whatever!

    Also, I've found that I can run all the orchestra players with 4 mix channels switched on and still at I/O Buffer 32, but in this case I need Large Process Buffer Range selected. Curiously, the total CPU load is in this case not far above what it is for the similar (4 audio channels each player) case at I/O Buffer 512.

    P.S.

    I forgot to say what recent major change I believe has helped hugely with my Synchron tasks.

    I now have all of my Synchron and Synchronized libraries in a new external SSD on its own Thunderbolt 3 port. That SSD is a Samsung 990 Pro 4TB M.2/NVMe/PCIe module (up to 7.5GB/s max speed) that I popped into an Acacis TBU405Pro M1 enclosure rated at Thunderbolt speed of 40Gb/sec max bidirectional transfer rate. In practice that means in sequential read and write tests, the Thunderbolt port maxes out at about 2.5 GB/s unidirectional (as normal). That's a downside (compared to internal SSD) only for clean installs and first-time app loading, etc; but certainly not a problem for the usual random reads during operation of the sample libraries. In the latter case, the ultra low latencies of the SSD and its enclosure still apply and provide market-leading speeds for random reads (as shown in an earlier thread).

    Yep, a somewhat expensive addition, and yep, I know the prices will fall. But I was indulging a bit of impatience and enthusiasm after I'd already replaced my Thunderbolt boot SSD with a 980Pro SSD (similar details as above) in an Acasis enclosure (same model as above), and noticed excellent results.