Audio dropouts when using two of the same Spitfire plugin (MIDI issue)

I’ve just noticed that when controlling two or more instances of the same Spitfire library (dedicated plugin, not Kontakt), there are audio dropouts when playing notes that are available in both of those techniques.

Repro sequence :

  1. Add two Instrument Tracks with the same Spitfire instrument (VSTi, not Kontakt)
  2. Make sure All MIDI Inputs is selected,
  3. Make sure the tracks are record enabled/monitored,
  4. Press some keys on your keyboard.
    Result → Audio dropouts occur.

These are not your average audio dropouts due to a performance overload, although the Peak meter makes a spike when this happens. Here the dropouts only occur when pressing and releasing the keys, and only when the tracks are monitored, and this happens both when playing live with a keyboard or when playing MIDI tracks.

Additionally, the issue only occurs when the notes have the same start and end positions (which happens naturally when playing with a keyboard). If you record MIDI on both tracks at the same time, audio dropouts will occur on playback, because the notes will be perfectly aligned.
However, when moving the notes a little in one MIDI Part, then the issue will go away !

Repro sequence :

  1. Record MIDI notes on the two tracks at the same time,
  2. Make sure the tracks are monitored,
  3. Hit play.
    Result → Audio dropouts occur.

  4. In one of the two MIDI Parts, select all the notes and move them a bit.
    Result → Audio dropouts do not occur anymore.

    OR (with the notes still aligned) :

  5. Deactivate record enable/monitor.
    Result → Audio dropouts do not occur anymore.

The issue is 100% MIDI related because the buffer size doesn’t play any role in this, the cracklings only occur on Note On and Note Off messages, whether the buffer is set to 64 or 2048.
Also, it doesn’t happen on every note pressed or read, this is random, although it becomes more frequent at lower buffers. And if I use different libraries on each track, this does not happen at all, so this is definitely not a CPU overload / performance problem.

This issue alone is extremely concerning, it really makes it impossible to play multiple techniques at the same time, for example Celli + Violins so that I can use more of the keyboard range.

So, is the issue coming from Cubase or Spitfire ?
Could some people please test this on their system ?

EDIT : Please see Post 25 for further details.

Nope, This doesn´t happen to me. Cello and Viola both recorded at the same time starting with Dm at D2. Then i played 8 chords over 8 bars. Put it in repeat for like 5 min and not a single time did any of the instruments miss a"note" not playing it. Record and Monitor on while recording on both tracks and both still on while listening in repeat. It works here at least.

I might recall that this has happened to me way way back in time. I think i restarted my comp and loaded up the project again and the problem was gone. I´m using Kontakt 7 with Spitfire . Not Spitfires Player.

Forgot to say that I’m only using the Spitfire plugin… I’ll edit the OP. Thanks for your input.
Also, it doesn’t “miss a note” but makes a short click, just like when the buffer maxes out.

However you can easily test this with LABS or BBC Discover if you don’t have any dedicated plugin.
I have tested with all of the six plugins I have, and the issue is present with all of them.

Another similar thing I have noticed with other non-Spitfire plugins, XLN Addictive Keys for instance, is when you hold the sustain pedal and press a lot of notes, when you release the sustain pedal it makes the Peak meter spike. The more notes that are playing before releasing the sustain, the higher the spike (and ultimately, if there really are too much notes active, it will max out and make a click, just like with Spitfire plugins). I believe Cubase receives too much “Note Off” messages with the exact same timestamp and just cannot process it properly.
My guess is that the same happens with Spitfire plugins, Cubase has to deal with multiple notes with the same timestamp on multiple plugin instances, and just fails to process it. Unless it really is a Spitfire issue ?

The last problem you describe, is because if you release the damper pedal a lot of release samples need to be played at the exact same time, not because of to many midi messages. I will try and check your original issue with BCC free.

Confirmed and also solved. In the settings menu of the spitfire plugin under audio, you have Preload size. If I increase that enough, it is solved. I started with maximum, which is 1000000 then half 500000 the quarter 250000, with the last one the issue reappears. I tried the same with Kontakt and it also has a little peak with 2 tracks record enabled, but no glitching.
If you use a lot of simultaneous spitfire libraries it will increase used ram a lot this setting. With the free BBC, from around 100mb to 700mb. For me I keep it at default as I never use 2 tracks simultaneously . BTW I run sata ssds, but on sata2 ports. M2 ssds might do better.

Well, yes and no, here’s why :

I tried with Discover and it indeed does seem to reduce the spikes (although Discover was producing significantly fewer spikes initially), but as soon as I switch to Core this is just not possible.
Discover is very light and only uses a few samples for the whole playing range, so the Preload size can be increased to taste and the performance can somehow improve.
But two patches in Core, however, already take 1.4 GB with the default 12288 value. If I change it to one million, it would just take hundreds of GB ! I have tried to go as high as I can go (literally 25 GB for only those two patches) but that did not fix the issue either, it remains exactly the same. As said on their website this is a setting for when we have slow HDD, and slow CPU, in other words when the plugin itself cannot perform well. With modern computers with fast CPU and SSD, we should not have to tweak this.

After testing more thoroughly, I came to the conclusion that this is a glitch that is exclusively related to MIDI processing (which confirms my initial thought), because when I record the group output on a track, or render the MIDI parts into one file, there is no dropout in the resulting audio files. Really, my guess is that some instructions may hang when the notes have the same timestamp, which creates a short processing spike and causes the ASIO buffer to skip/dropout.

It means the issue is totally unrelated to the settings you suggested to tweak. The plugin itself performs very well, as this is not the plugin that drops out, but Cubase. You may believe that increasing the Preload Size fixes it, but that’s not the case, it indeed helps reducing the CPU usage, but the underlying issue is still there, it is only less noticeable because the CPU is more relaxed, so it is less likely to max out and cause a dropout, but it’s there.

And not to mention that the issue happens with LABS too.
So clearly, this tweak hides the issue but does not solve it.

I’ll get in touch with Spitfire.

Hi Louis, talking to you is really terible, you always know best, even when that is not sure (I am not saying not true). IMHO it is a fault with how spitfire processes simultaneous midi notes. Kontakt does that more elegant for some reason (yes I tested).
I agree with your thoughts about BBC explorer vs full. but, just think about it, the number of midi notes is the same, only the number of samples that needs to be started is different, so it is either a streaming samples or starting many samples at the same time by spitfire issue.
If you are not more friendly now, this is the last time I try to help you! It did spend time on this just for you!

1 Like

I’m sorry for that, your help is much appreciated, as it permits to try new things in order to pinpoint the issue correctly, so, thank you.

Real workaround fix is at the bottom of this post :wink:

What I mean is that I have two BBC instances. Violins 1 and Celli.
They both load their own samples (files) into the RAM.
When I hit C4, it has to play Violins 1 C4, and Celli C4, which are two different files, right ?

So how difficult would it be to play them both at the same time? This is just one note pressed, and two files triggered! And this is exactly the same whether we’re using Discover or Core!
Since the patches have their own different files, this should not be an issue.

As far as I know, the number of “files” that needs to be started is exactly the same, or at least roughly the same, Core can have up to 4 or 5 files playing at the same time per note, due to the dynamic layers and vibrato that mix together. But this should not impact the performance. It’s like playing a single plugin with 100 notes playing at once. If I can do that, then why can’t I simply play a single note on two plugins without the audio engine going crazy ?

Also to remove the sample/file wording confusion, the Preload Size isn’t about storing more or less “files” into the RAM, it is about making the actual sample values ready to stream at any given time for every available files. For example if the files are 48 KHz (so 48,000 samples per second), it decompresses and makes ready the set number of samples, which is 12,288 by default. When you press a key to trigger a file, it immediately starts playing the readily available samples, and during that time the following data will start to decompress. So setting a higher value just gives more time for the CPU to decompress the files.
Preload and Stream Buffer Size works exactly the same, except Preload is for making the data ready to stream, and Stream is for when the files are already streaming. As you may have noticed, the RAM usage increases a bit when notes are playing, because the files will continue to decompress as they are streaming.

image

The thing I don’t understand is that it talks about “hard drives”, whereas when we load a patch, all the audio files are directly loaded into the RAM. All the subsequent processing is only made between the RAM and CPU. I have never ever seen any disk activity when playing instruments, so maybe they mean slower RAM ? Because slower RAM takes more time to decompress and read, so the more readily available data the more reactive it is, but on the other hand it takes more RAM. At least this is how I interpret it. I don’t see what meaning that could have otherwise :man_shrugging:
Increasing the values won’t help a slow drive, if the drive reads at 80 MB/s, a higher Preload Size value won’t change anything to that, the drive just won’t simply fill the RAM faster because of this. WTF.


Workaround :
After testing again, I have found out that disabling Multi Processing in Cubase (Studio > Studio Setup > Audio System) fixes the issue permanently, but doing so greatly reduces Cubase overall performance…

I’ll contact Spitfire, but Steinberg developers should investigate this ASAP too.

No problems with LABS or BBC Discover here. Added 2nd Violins Long in this aswell. Every setting in Discover/LABS at default.

You know what the problem is Louis_R ?

To much ProN surfing :joy:

The spitfire engine uses disk streaming, like any other big sample engine. It doesn’t load all samples immediately into RAM.
I can’t reproduce it here with Discover with four instances and a three note chord, then peak performance hits red and i get the occasional dropouts @256 buffer size. They vanish when I switch to 512 buffer size.

Pretty sure it has to do with the disk streaming in the Spitfire engine in some way and not with Cubase… Funny that it vanishes though when moving the events a bit. Some thread syncing/locking problem maybe? Spitfire does seem to do some internal multithreading, probably exactly for disk streaming purposes.

Btw, I can load ten instances of Kontakt with NY concert grand, no problem at all. But then NI do have a few years ahead of the competition regarding disk streaming…

That’s interesting. In the spitfire plugin I indeed see the disk usage increase by a few percent, but if it’s really the case then this is definitely not reported to Windows. I have no way to see the disk read/write. And wouldn’t the RAM increase drastically as we are playing ? This doesn’t seem to be the case either. The only thing I notice is that the RAM only increases by a few MB when the notes are playing because of the files decompression.

To me it really feels like all the files are already stored into the RAM, I can bash the keyboard with my foot on the sustain while switching between techniques rapidly and I never have any disk usage.

I don’t know what happened honestly and maybe it’s little of topic. But I have audio drops on Windows 11 with 18-Core 3.00 GHz Intel Core i9-10980XE… I have 128 gb of Ram. Was tested with latencymon…
And when I tried to set buffer to 128 and play chord with 4 notes on based NI Action Strings 2 in Kontakt 6 I hear the drops… really strange… seems that all sound in one core… does kontakt 7 more good with multi processing? Who know?
And should I set up 16 cores in Kontakt settings if I have 18?

I don’t know where you are looking in Windows, I used Process Explorer and looked at the Performance graph for Cubase, I see a definite correlation between hitting the keys and subsequent reads. not many, though. You can also see the reads from the spitfire sample file in Process Monitor.
My absolutely uninformed guess is that they have some shared buffer pool for the samples between instances, with some worker threads, and if the same note at the same time, multiple threads read the sample data and want to write the data to the pool, but have to wait because there is locking involved of course. Grossly oversimplified, and I could be totally wrong, but just reading that little data from today’s solid state drives can’t be the problem, it has to be some thread syncing problem imho.

If you hear something from Spitfire, let me know!

1 Like

Yes I see now, but I really need to play a lot of notes, the usage is only a few hundred KB with just a few chords. Resource Monitor catches it better than Task Manager. Actually Task Manager showed no activity at all with BBCSO or ARO, so this is why I said there was none at first, I’m sorry for this. I imagine in large project this can reach much higher values.

It seems that their flagship plugin libraries do load (almost) everything into the RAM compared to LABS. The disk stream is much higher with LABS. With bigger libraries I really need to play a lot of notes before it kicks in for good.

Anyway, in the present case it isn’t a setting issue or some performance bottleneck, since it happens when pressing only one key. So as you say, it’s more of a processing/instruction issue.

I’ll keep you informed when I get an answer :wink:
I’ve seen some topics on the Spitfire forum that expose the same issue. Their answer is to get a better CPU lol. The thing is when we turn off multi-core in our DAW (and that reduces the performance…) it fixes the issue for real. :laughing: So, buy a 16 core CPU, but turn off multi-core so the plugin only uses 2. Looks fun. They’ll hear me.

Louis, you can also easily turn of hyperthreading, either in the bios or with process lasso app. I would not be surprised if it fixes it

I think I would be surprised if that would fix it :wink:
The application (in this case the plugin) doesn’t care or know about hyper threading, it just creates threads, where and how those are scheduled on the CPU is the task of the operating system kernel.

We will see when he tries :wink:
The reason I would not be surprised is that
1: Disabling multiprocessor helps (that disables HT too for cubase) and this otherwise does not make much sense
2: I still use Vienna ensemble pro 5 which is unusable with HT on (crackling), so it does happen.

Disabling multiprocessor helps because Cubase runs the whole audio engine in just one thread (which then gets scheduled to different cores though by the OS), and somehow Spitfire detects that (how I don’t know) and doesn’t create its own thread pool (or whatever you want to call that) and runs simply single threaded, thus evading the problem.
Where do you get the information from that disabling multiprocessor also disables HT for Cubase? according to my tests, it seems to do that for the audio thread, but I have no way of confirming that, only from looking at the CPU perf graph in Process Explorer, where the majority of cpu usage from Cubase is on two to three different cores (on my 6core/12thread machine). But then I am not versed enough in Windows scheduling… only uninformed speculation on my part :grin: Interesting, though

1 Like

It disables HT by definition, since it uses no multi processing. Of course the cpu is still using it. You can not change HT on cpu level from software.
HT advantage is more usefull/used cpu cycles, disadvantage is more chance on micro delays. You only have the illusion of 12 threads running in parallel, In reality it is 2X6 serial.
The extreme switching of (HT) cores is not only done by windows scheduling but also on a hardware level by intel. You can disable this (at least with my 6core 12 threads) laptop by disabling thermal management (whatever it is called exactly) in the bios, then the switching from core to core stops, but the CPU runs much hotter.
On my laptop I use precess lasso for disabling HT for VEP 5 so I can leave it on on hardware level. It sets the affinity for VEP to cores 0,2,4,6,8,10. This has the same effect as disabling HT on bios level. It is even a preset in process lasso, disable HT. VEP is unusable with HT on for some reason, but I use an old version, so probably fixed for years now, but I don’t use it enough to warrant the upgrade fee.

@vinark First, my i7-9700K doesn’t even have Hyper-Threading, so it’s turned off and grayed out in the BIOS. It only runs on 8 physical cores.

You seem to be confusing Hyper-Threading with Multithreading :

HT is a CPU thing only. It splits all the physical cores into two logical cores, so you have twice the number of cores available. And this increased number or cores is what is reported to the system.

The Multi Processing option in Cubase is similar to the “Multi Core” enhancement you can find in other software (this is called Multithreading). It has nothing to do with HT, this only sets on how many cores the software can run.
If you disable it, Cubase has to run on less cores, and since it can no longer split certain tasks to additional cores, it loses a lot of performance as it has to run multiple threads on the same core. Instructions stack up and it takes way more time to process. There really is no HT involved in this.

It’s up to the system to decide how HT is used. Since twice as much cores are exposed, they all have half the transistors to work with, so bigger instructions may need two or more cycles to process instead of just one, but with modern CPU with fast clock and high transistor count, this is not a problem anymore.


Your problem with VEP does not surprise me. First you are using a laptop, and laptop CPUs have much lower transistor count than desktops, and lower clock speed too. So basically, if HT is enabled, the transistor count is halved for each core, and VEP will just bottleneck because it needs too many cycles to process one single instruction. Well, that’s the theory.

You say that setting the affinity to specific cores fixes your performance issue, but in reality the program is still running on logical hyper-threaded cores, so I believe that’s more of an issue with how the software schedules the instructions…