Vienna Symphonic Library Forum
Forum Statistics

195,441 users have contributed to 42,987 threads and 258,254 posts.

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

  • Much appreciated, thanks Paul.  Got our little pro composer community doing some testing on different rigs / setups, I'll pass on anything useful we find here.


  • Paul,

    I side with noiseboyuk's assessment. I also have issues with Cubase Pro 8 running on a 12-core Mac Pro (2013) Mac OS X 10.9 with plenty of CPU power and am getting severe CPU spikes, audio dropouts, and distorted audio across the complete audio buss as long as ASIO-Guard is enabled. 

    In my template I have 1,000+ MIDI tracks connecting to 50+ VE Pro Rack Instruments that connect to three workstations. I have not tried to run with the ASIO-Guard lowest setting, as the other two settings caused such severe issues that I simply just disabled it.

    Just another viewpoint. :-)

    Jurgen


  • I suggested that some chaps from the  ViControl composer forum share experiences here as well.  My impression is that this will be the most pressing issue for all VePro / CP8 users out there to be solved. 

     


  • The issue with audio dropping out when switching tracks, is probably due to latency for VEPro varies with buffer size. VEPro reports its new latency to Cubase, which has to recalculate its latency compensation - causing a drop-out in the audio stream. It appears that Cubase does this instantly, while a latency change reported to for instance Logic Pro, will only take effect from the next stop/play cycle - which sounds more reasonable to me.

    We are looking into this behavior and will try to improve the situation asap.

     

     


  • Thanks Martin, really appreciate you guys looking into it so quickly.


  • last edited
    last edited

    @MS said:

    The issue with audio dropping out when switching tracks, is probably due to latency for VEPro varies with buffer size. VEPro reports its new latency to Cubase, which has to recalculate its latency compensation - causing a drop-out in the audio stream. It appears that Cubase does this instantly, while a latency change reported to for instance Logic Pro, will only take effect from the next stop/play cycle - which sounds more reasonable to me.

    We are looking into this behavior and will try to improve the situation asap.

    You're not supposed to work on a Sunday Martin. ðŸ˜‰

    Thanks for looking into it! - Best G.


  • This is mentioned in the Steinberg knowledge base. When you select a MIDI track and record enable it, the track is no longer in ASIO-Guard mode and the sound mutes as it switches over to real-time mode (and your normal latency.)

    This seems to be in addition to what Martin describes.


  • last edited
    last edited

    @johnstaf said:

    This is mentioned in the Steinberg knowledge base. When you select a MIDI track and record enable it, the track is no longer in ASIO-Guard mode and the sound mutes as it switches over to real-time mode (and your normal latency.)

    This seems to be in addition to what Martin describes.

    I can't see a specfic reference to that in the Cubase 8 issues - https://www.steinberg.net/nc/en/support/knowledgebase_new/show_details/kb_show/cubase-8-version-history-and-issues-and-solutions.html .  The sound neither mutes on other plugins or VE Pro under very favourible conditions.

    I do have a feeling though that some of this might be Steinberg's end, you do tend to get a CPU spike when switching tracks in general (though that hasn't caused me any audio problems save for VE Pro).  Though I can't pretend to understand the inner workings of these things, if asioguard's delay is 90ms, I guess a dream scenario is being able to seamlessly switch from prefetched audio to live latency audio somehow 90ms afer a track is enabled.  Might not be possible though.


  • last edited
    last edited

    @noiseboyuk said:

    Hi Paul, as you may well be aware asioguard 2 is rewritten in Cubase Pro 8 from the old one in 7.5.  Pretty much no-one used it in 7.5, it usually caused more problems than it solved.

    The situation is very differernt in Pro 8, however.  The vast majority of people are seeing significant performance gains with it.  Further, I concur with others that performance without asiguard 2 switched on actually is slightly worse, so that's all the more reason why asioguard 2 ON will become the norm now, very much not the case with asioguard 1.  I can pretty much guarantee you'll soon get a flood of issues on this as a result - Cubase is the DAW of choice for a very large number of professional composers, a large number of whom use VEP.

    The fact that it works cleanly for me at the lower setting but very much not at normal or high suggests that there's an issue somewhere between the new engine and VEP which is able to be addressed - respectfully I'd ask that this is investigated a priority (though of course you may determine the issue is at Steinberg's end - I've submitted the issue report with them also)

    One final thing - I just heard a report that someone is running ok with VEP 5.1.12331, though I need to confirm what their asioguard status is.

    +1 VEP needs to play nicely with ASIO guard. Please make it happen guys. 


  • I am getting the same experience with Cubase 8. Have tried ASIO guard at Normal and Low but it only works when totally switched off and then the latency is very noticeable. This seems to be restricted to VE Pro and not when you just load VI Pro. It would be much appreciated if it could be investigated as although Cubase 7.5 works with ASIO Guard switched off, clearly many people will upgrade to 8.

    regards, woy


  • last edited
    last edited

    @woy said:

    I am getting the same experience with Cubase 8. Have tried ASIO guard at Normal and Low but it only works when totally switched off and then the latency is very noticeable. This seems to be restricted to VE Pro and not when you just load VI Pro. It would be much appreciated if it could be investigated as although Cubase 7.5 works with ASIO Guard switched off, clearly many people will upgrade to 8.

    regards, woy

    It's related to all multi timbral instruments, and Steinberg recommends not to use them. Like that's going to happen....

    DG


  • last edited
    last edited

    @Another User said:

    ASIO Guard 2 uses low latencies just on the tracks where latency matters while using a larger latency that saves performance for playback tracks. It now supports instrument tracks including multi-timbral and sample instruments that feature disk streaming. 

    http://www.steinberg.net/en/products/cubase/whats_new.html


  • last edited
    last edited

    @Another User said:

    ASIO Guard 2 uses low latencies just on the tracks where latency matters while using a larger latency that saves performance for playback tracks. It now supports instrument tracks including multi-timbral and sample instruments that feature disk streaming. 

    http://www.steinberg.net/en/products/cubase/whats_new.html

    Actually, I think that you're just under informed:  ;>😉

    "In Cubase 8, multi-timbral VST Instruments are running in ASIO-Guard mode, too, which enhances performance additionally. However, multi-timbral VST Instruments will be switched to real-time usage as soon as a MIDI track is selected, that is assigned to the instrument. This may increase the real-time processing load significantly and cause drop outs. The performance drop when switching from ASIO-Guard mode to real-time can be softened by using multiple mono-timbral VST Instruments instead of a single multi-timbral VST Instrument."


  • A source for that quote would be useful DG - can't see it in the manual or Knowledgebase.

    It is of course completely logical that multitimbral will increase the resource load.  The only relevant question is whether or not that's an issue in practice.  So for for me it has not been, using Kontakt, Omnisphere, Stylus on my i7 4930 @256 - all safely within limits.  Your asioguard vs soundcard settings will depend on a large number of factors.  But key is assessing what proportion of your overall CPU load you'll need to access live at any one time. If you have, say, 30 multitimbral instruments, logically you could reduce the realtime load to only 1/30th of what it was using asioguard (all other things being equal).  However, if you're on a modest system where you were struggling with only one multimbral instance, asioguard won't help you at all if you keep it that way - you'd be much better off spreading the load among monotimbral instruments as your quote suggests.  Most pro users will have powerful rigs and quality soundcards though, for them this advice should be fairly moot - hence perhaps why they are talking it up on the main what's new page on their website, specifically mentioning multi-timbral compatiblity.  Would be very strange to talk it up there and later say you shouldn't really use it.

    Anyway, the only real issue so far for me has been VE Pro 5. Incidentally, I did hear that VE Pro 4 behaves much better with asioguard.  That would be interesting if so.


  • last edited
    last edited

    @noiseboyuk said:

    A source for that quote would be useful DG - can't see it in the manual or Knowledgebase.

    It's in the Knowledgebase. Down the bottom under Cubase 8 ASIO Guard.

    https://www.steinberg.net/nc/en/support/knowledgebase_new/show_details/kb_show/details-on-asio-guard-in-cubase-and-nuendo.html?tx_p77sbknowledgebase_pi1[keyword_search]=ASIO%20Guard

    DG


  • Hopefully VSL will offer a fix via a VE-Pro 5 update. 

     

     


  • Thanks for the link.  Yes, my interpretation of that is that is exactly as my previous post.  Unless you're pushing things to the absolute limit or if you are very stretched on resources, you should be fine with multi-timbral.  I see no reason for those who have templates and workflows using multitibral to change things.

    We're kinda off topic at this point - VE Pro falls over on standard settings with just two instances containing one instrument.each.

    Would be very curious to hear reports of anyone using VE Pro 4 - I understand that works much better.


  • I have disabled ASIOguard on my system at home. I have duplicate setups at my studio and at home: each location has a host PC (HP 810) running a VEP server + Cubase Pro 8 and a slave PC (Dell 7500) running another VEP server. There is only differences between the 2 locations are the audio interfaces: my studio setup has the Fireface UC RME (USB), and at home I have the Yamaha MR816CSX (firewire).

    Every week I work some in the studio and some at home (I sync my projects through Google Drive & Dropbox). My work is all MIDI, and I have around 500 MIDI tracks in my template (organizational folders and group/fx tracks push the track count to 900+).

    At my studio, I left ASIOguard running - default after Cubase 8 upgrade. Everything ran just fine there, but when opening the same project at home, I experienced dropouts and crackles. As soon as ASIOguard was disabled at home, everything was perfect.

    As a side note, I found a utility for the MR816CSX that increased the firewire buffer of the unit. The factory setting buffer size is set to "small!"

    Hopefully, that helps someone or provides another thing to look at when troubleshooting.


  • A couple of additional thoughts.....

    It has been reported by several users that VE PRO 4 does not have this ASIO Guard 2 problem.  

    I can say in my giant template when I switch from various non-VE PRO 5 instrument tracks I do not have any delayed sound issues at all.....only when switching to or from various VE PRO 5 instruments.   Switching to different midi tracks on the same VE PRO 5 instrument is fine, the problem happens when you switch do a different VE PRO 5 instantiation.

    Another major issue when I have ASIO Guard 2 on is that I get huge 100% ASIO spikes often when a tempo change happens.  I still think this is related to something in VE PRO 5 as many of us have discussed tempo change problems that cause CPU spikes when using Cubase/VE PRO 5/and usually Kontakt.

     

    Hopefully they can get this sorted out soon.