Query on iLok decryption CPU-burden in realtime streaming [Edit].

[Helmholtz]

Dear VSL, I realise this might be a potentially embarrassing and unpleasant topic for you but here and now I must take the side of your current and potential customers. I trust you understand.

Am I right in assuming the following 5 statements are true? ....

1. In all of VSL's iLok libraries, all sample audio is PACE(iLok)-encrypted prior to download and installation.
2. A fresh or moved installation of a VSL iLok library does not finally decrypt the sample audio.
3. 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.
4. 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.
5. 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.

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.

I for one would much prefer to tolerate slower installation or preloading if it means realtime streaming is thereby relieved of most if not all of the CPU's current heavy realtime decryption workload.

I realise that iLok's very tight security appears to depend simply on keeping all sample audio fully encrypted while in the user computer's storage. But then again I'm in no way assuming or suggesting that iLok's design approach is the one and only option open to VSL over the long term.

I've a suspicion that many VSL customers have been feeling somewhat railroaded into buying new and more powerful computers, in large part just in order to make up for the substantial added CPU burden of realtime iLok decryption, as compared to the E-Licenser days.

As I see it, if nothing is done to redress this technical and commercial disadvantage and it becomes identified as 'VSL's hidden price overhead' or some such idea, then over the long term, attracting new customers to VSL and keeping current customers might perhaps be rather more difficult and elusive than it need be.

[ravez]

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?

[Ben]

We make sure that our protection system does not noticable impact real-time audio.

[Helmholtz]

Yeah, ravez, that behaviour of the Synchron Player has given me cause for puzzlement too.

Is it that that sometimes certain samples haven't yet been placed in RAM by Preload (either because the Preload size is a bit too small or perhaps because the machine just ain't got enough free RAM to satisfy Preload) and so have to be fetched from storage first? Then perhaps it's a catch-as-catch-can game between the various tracks and CPU threads who all want their samples ready preloaded in RAM but not all can be satisfied?

I find it hard to deduce what exactly is going on there.

[Ben]

@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.

[Helmholtz]

Ben, appreciate your two comments above.

I'm still unclear as to what exactly happens where, when and under what circumstances, since even knowing the realtime privilege priority level of each process still doesn't help us predict the order of asynchronous realtime event processing - any more than merely stochastically.

And since I'm not in a lab with very expensive analytical lab instruments at hand, of course I'm not expecting to arrive at any exact answers to my investigations.

My broad-brush postulates and questions at the top still stand, however.

[Ben]

I can't comment more detailed, not only are we're under NDA, but also is it in our best interest not to reveal details regarding our copy-protection.

Like I said, real-time performance is not degraded by our copy-protection; it's important to us to provide the best user experience and that's why we make sure it stays that way by regular internal testing.

[Helmholtz]

Thanks for that, Ben. Understood about NDA and VSL's own commercial confidentiality. I wouldn't expect it to be otherwise. And there's no suggestion here of the quality of VSL's development and testing being at any time less than the usual high standards we've come to know and respect. I'm talking about certain exigencies that arose and had to be faced and promptly dealt with by VSL - namely, the impending discontinuation of E-Licenser.

The hard evidence that got me started on my current experiments and thinking came in the form of 3 readouts from the Synchron Player's random-access speed meter. All 3 of these SSD speed readings were pre-iLok (2 from Stephen Limbaugh; and 1 embedded screenshot in the Synchron Player user guide that I seem to recall from back in the days of Synchron Strings 1).

It appears to me that those Synchron SSD speed test results are pretty much impossible to replicate now - even roughly - with iLok in the game. As many Synchron users have already noted in this forum since the introduction of iLok, something is - or some things are - very different in streaming performance between then and now.

Also, the essentials of my basic understanding of iLok's security system comes from iLok's own published information.

I'd still appreciate a word from Paul tomorrow or soonish if possible. This isn't an urgent matter, but I do believe it's important for many VSL users and, ultimately, for VSL itself.

[Ben]

@Helmholtz said:
The hard evidence that got me started on my current experiments and thinking came in the form of 3 readouts from the Synchron Player's random-access speed meter. All 3 of these SSD speed readings were pre-iLok (2 from Stephen Limbaugh; and 1 embedded screenshot in the Synchron Player user guide that I seem to recall from back in the days of Synchron Strings 1).

The player measures 2 different kind of disk speeds, it might be that the other value is now shown. Regardless, this doesn't change performance or how Synchron Player handles things.

@Helmholtz said:
with iLok in the game.

Again, nothing to do with iLok, a lot else has changed in the meantime, and if I remember correctly the streaming code was refactored and optimized post iLok launch. With the latest version(s) you will have better performance compared to any eLicenser build.

@Helmholtz said:
As many Synchron users have already noted in this forum since the introduction of iLok, something is - or some things are - very different in streaming performance between then and now.

I have not seen any complains or discussions of this kind in a long time, and last time I experienced streaming issues was with eLicenser variants of the player.

@Helmholtz said:
I'd still appreciate a word from Paul tomorrow if possible. This isn't an urgent matter, but I do believe it's important for many VSL users and, ultimately, for VSL itself.

I have no idea what you expect from Paul to add to this discussion tbh 😊
And I also don't get it why this is an important topic. If you experience unusual performance issues you should contact support@vsl.co.at. This is not a support-, but a user-forum.

[Helmholtz]

I hear what you say, Ben. Many thanks for your comments.

What I'd very much like Paul to address if he gets time is my pair of questions at the top ... "if VSL can envisage ..." etc.

(My thinking behind the 1st option is that it would probably require a pretty radical redesign of the anti-piracy system - with or without iLok. The 2nd option involves a tradeoff - do we wait a bit longer for preset loading by making preloading take care of decryption in order to speed up subsequent realtime streaming, or do we put up with the current streaming performance limitations due to the current extra CPU burden of stream decryption in realtime? And of course I would certainly never be asking Paul to frame any sort of answer in such specific terms.)

[Ben]

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.

[Helmholtz]

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.

[ravez]

@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

[Ben]

@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.

[stephen limbaugh]

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?

[Ben]

@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.

[Helmholtz]

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.

[Helmholtz]

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 limbaugh]

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.

[Helmholtz]

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.