eratu


From this I can make yet another obvious recommendation: When in doubt about dropouts, disable Aero!

This was exactly my finding when I first tested Vista x64 using the Sonar Benchmark test.  I got much better performance at low latencies with Aero turned off. 
 
Thanks for confirming that I was not crazy :-)
 
 

Nice job dude!

By the way, what's an average project for you?

I'll be waiting for the news on the big papa project :-)

An update:  Another plugin I am having issues with is POD Farm.  Half the time the presets load and the components of the chain are "off" and have to be turned off an on to get them to work.  Have tried both bitbridge and jbridge.  Will try the new 1.16 version of jbridge tonight...

EDIT: ...no joy with jbridge.  Also, a strange thing happens from time to time where it doesn't "see" models that are authorized and gives me a "this preset uses a model that is not authorized".  Shutting SONAR down and restarting seems to fix it.

Hey John,

To be fair, I re-tested using the Sonar Benchmark test and now I get equal performance with and without Aero at the lowest latency (48 samples) in Windows 7 x64.  But Windows Vista x64 didn't give me the same results and would perform better with Aero OFF using the same test.  Actually, I believe I wasn't even able to run this project at that low of a latency.  The lowest I could do in Vista (if I remember correctly) was 64 samples, so this is really awesome.  I wish I had my notes from when I tested Vista so I could be certain.

This with Aero OFF is just crazy!


I hear you but still crazy? Sounds to me more like graphic driver issue...It should perform better with AERO ON!
OFF will always be the---> wrong setting no matter what! Its not a solution work without AERO. Its a part of the OS so the system doesn't perform and work as it should when having the AERO OFF!



It shall always be set to--->ON!
Personally I hope Microsoft take this OPTION away soon so you can't shut it OFF!


Best Regards
Freddie

It shall always be set to--->ON! Personally I hope Microsoft take this OPTION away soon so you can't shut it OFF!

Not a good idea Freddie because some laptops would have a great deal of trouble if it could not be turned off. Everything depends on how good the graphics system is on any given machine.

John

This was exactly my finding when I first tested Vista x64 using the Sonar Benchmark test. I got much better performance at low latencies with Aero turned off. Thanks for confirming that I was not crazy :-)

This needs to be further discussed.  I am wondering why this should be. Areo should have nothing to do with low latency. If this proves true with Vista/Windows 7 64 then it ought to be true of Vista/Windows 7 32 as well.

I wonder what is your graphics subsystem and how is it configured?  What drivers you are using and anything else you can think of that could shed light on this.

Hi John,

To be frank, I think it's a combination of Win 7 x64 + my graphics card + my graphics card drivers + my audio devices + plus their drivers + Omnisphere x64 or other similar plugins

I'm using an NVIDIA Quadro FX570 with the latest WHQL drivers. The main audio device is a Lynx L22 running the latest beta build of their driver.

Now, over in the Lynx forum, we're having a discussion about this and if I understood it correctly, one of the developers said they were having some issues with NVIDIA cards and the latest driver on Win 7 x64. So it could be isolated to that platform/combination. However, apparently, the native Win 7 x64 NVIDIA driver does NOT have problems with the latest Lynx driver. I have not tested this... but the implication is clear that there may be something that is going on with the Win 7 x64 NVIDIA drivers specifically.

To clarify further on my situation, I seem to be able to get equal low-latency performance with Aero ON or OFF... the difference is that I cannot get 100% clean playback when I use certain plugins, such as Omnisphere x64... AT ANY LATENCY THAT I TESTED. So this is not limited to low-latency situations. I tested 32, 64, 128 and 256. At all those latencies I will get occasional, random, unpredictable, rare clicks/dropouts. I didn't notice at first, since it is rare, but if I just sat there holding a chord long enough or playing an Omnisphere patch for a while at any of those latencies I'd get a little random click WITH AERO ON.

With Aero OFF, those clicks appear to have disappeared, except for the FIRST TIME I open the Omnisphere interface during playback. Omnisphere x64 hesitates just before opening the first time, and it causes a single tiny dropout on my system (according to the Lynx mixer, which reports number of dropouts), even with Aero off, in both Cubase and Sonar. In Reaper, this doesn't happen. I don't mind this situation at all, and we clearly know what the culprit is, and it's no big deal.

Also, I tested this with the Sapphire Pro 40, and my initial tests are very similar... at 128 or 256 sample latency, and AERO ON, I get some rare, random clicks when using a plugin like Omnisphere. With AERO OFF, the clicks seem to go away.

This leads me to believe that if we're going to assign any primary blame to whatever is going on in my ecosystem, the common factor is the NVIDIA x64 driver. But again, it's probably more than that -- a combination of issues. (EDIT: OR, it might just be Omnisphere! I'll be testing some more today.)

Anyway, bottom line with my system so far is that with Aero turned OFF I'm getting the type of smooth performance I was hoping for.

Freddie H


This with Aero OFF is just crazy!


I hear you but still crazy? Sounds to me more like graphic driver issue...It should perform better with AERO ON!
OFF will always be the---> wrong setting no matter what! Its not a solution work without AERO. Its a part of the OS so the system doesn't perform and work as it should when having the AERO OFF!



It shall always be set to--->ON!
Personally I hope Microsoft take this OPTION away soon so you can't shut it OFF!


Best Regards
Freddie

I agree something is crazy, but I think it is a subtle issue that will hopefully get worked out by the various developers involved.... and I definitely disagree that Microsoft should remove the option to shut Aero off. These machines are so delicately balanced, I want to be able to disable any part of it I can in order to improve the system if I need to. Not to mention that there is a lot of hardware out there that can't run Aero anyway.

Ahhhhhhhhhhhhhhhhhhhhh!

Now this is just annoying. I hate when I get different results in the exact same situation.

I turned Aero back ON and this time in Sonar x64, I DID NOT GET ANY DROPOUTS WITH OMNISPHERE, except when I opened the Omnisphere interface for the first time. After that, I tried for a good 15 minutes to get a dropout, interface open, interface closed, etc..... Solid as a rock both ways. At 32 samples latency and at 128 samples latency.

Now in Cubase, I DID get one dropout when the Omnisphere interface was open with Aero ON in addition to the dropout I got when I opened the Omnisphere interface for the first time, but NO dropouts when the Omnisphere interface was closed in this brief session/test.

NOTHING changed on my system, except I was now paying attention to whether or not the Omnisphere interface was closed/minimized, and deliberately testing it with the interface closed. Yesterday, I had been going back and forth with Aero ON, Aero OFF, etc... But this time, for some bizarre reason, Aero ON + Sonar x64 + Omnisphere x64 interface open or closed = NO dropouts.

I repeat, AHHHHHHHHHHHHHHHHHHHHH!

Lesson? I have no idea what to expect the next time I try this. At least I know opening and/or viewing the Omnisphere interface has something to do with it. Maybe this is a really weird Omnisphere x64 + NVIDIA issue. I do know that I don't get any dropouts in any of the apps with Aero OFF... but that has to be refined further with this test. I'll be keeping my eyes peeled and ears open in the days/weeks to come and see if I can detect another pattern.

John

It shall always be set to--->ON! Personally I hope Microsoft take this OPTION away soon so you can't shut it OFF!

Not a good idea Freddie because some laptops would have a great deal of trouble if it could not be turned off. Everything depends on how good the graphics system is on any given machine.

Agree! I take it back! 
 
 
Regards
Freddie

UPDATE:

I can get BitBridge to crash with AAS Ultra Analog VA-1 1.1.2 -- if I have time, which I don't, I'll try to see if I can come up with a recipe for the developers. :(

Feeling the annoying side of my move to x64. Grrrrrrrrrrr........

Makes me want to throw ALL of my x86 plugins in the garbage. But course, I can't do that. I can't live without some of them. Damned if you do, damned if you don't.

Thanks, Jose, you rock, as always! For now, I'm just collecting information and doing basic testing, etc.

I'm getting unpredictable strangeness here and there with plugins I thought were working fine. Combinations of plugins cause strangeness. For example, I managed to crash BitBridge with AAS Ultra Analog VA-1 1.1.2 plus a few other plugins. All of those plugins seem to work okay by themselves. :( I'm still testing, but pulling my hair out. I have to test them by "fire-walling" them off into their own BitBridge servers... this becomes a pain in the neck to keep track of and manage.

I also managed to get JBridge to crash on at least one plugin, possibly two -- Arturia strikes again. Ahhhhhh! That means I have problems in both BitBridge and JBridge when it comes to Arturia. A potential no-go for Arturia for me. There was a combo that didn't work AT ALL, so I'm going back and testing a little more. Feels like a waste of my time but I love the sound of Arturia!

Then in Cubase x64, it is a car wreck as far as VST Bridge when it comes to certain plugins. I haven't been able to sort through which ones it can handle and which ones it goes crazy with.... it is so tedious to test! A total, steaming pile of crap, which will take me some time to figure out. VST Bridge is even more embarrassing than I thought before. Wow. Load up 5-6 plugins in VST Bridge and inevitably one or more of the plugins will have issues which might bring the whole thing down... slow response to closing windows, and even crash! Just a complete joke. I'm at the point of giving up on VST Bridge and trying to set up all the plugins with JBridge, but some of those don't work well with the Cubase-JBridge combo, even though they might be okay in Sonar-JBridge... still sorting those issues and double-checking.

Anyway, no worries. Most of the "critical" ones are indeed good inside Sonar x64... but then again, I thought Ultra Analog was fine until today. Bam! Crash of BitBridge on that one. Not good.

So I'm not out of the woods yet. However, the issues are mainly with less critical plugins.

One by one I'll figure this out. It's mainly an issue of confidence. I don't have confidence in a number of plugins, and I'm trying to keep track of which ones work for certain with the various bridges.

For example, I use Reaktor in several of my projects. Reaktor seems to work fine with Sonar's BitBridge. So I'm okay there. But in Cubase x64, it does not work well, especially in combination with other plugins... so I tried it in JBridge, and I got some weird glitching at the beginning of some of my patches, and the JBridge plugin window doesn't resize without a close/re-open when I bring up an ensemble. Very annoying. So I'm not too thrilled with Reaktor within Cubase.

And BTW, Reaktor seems to work fine with the Reaper bridge... why doesn't that surprise me?

Ironically, the bridge that is giving me the LEAST hassle today is Reaper's bridge! That sneaky Justin came up with something that seems pretty decent so far. More testing ahead, so that's preliminary. But my initial testing has been very favorable.

Sonar's BitBridge is still the best overall, in my opinion, notwithstanding its issues. I just have more confidence in Sonar x64 as a package at this point, but that's also partly a function of having spent more time on this issue with Sonar. Reaper, with its inferior MIDI, is not really a realistic option to compose with anyway (for me, personally, I'm not knocking Reaper for people who use its MIDI), so the alternative in the x64 space is really Cubase right now.

However, I can categorically say that Cubase VST Bridge is next to worthless for me at this point.

Anyway, I'm just feeling frustrated and tired tonight. I know if I ignore the misbehaving plugin combinations, then the majority of the critical plugins are fine, so this is not an emergency situation.

If I can wrap my head around the issues and strip them down to the core problems to test, I'll post about it. Maybe you (or someone else) will have some added insight or ideas. At this point, I'm tempted to throw the whole damn collection of problem plugins in the trash.....

Nahhhhh. I'll stick it out some more...

Keep at it James.
We'll have your fallen body to use as a bridge when we all finally cross to that great big 64 bit land on the other side.

Just kiddin'.
I'm just glad I'm not using your collection of plugins nor am I using SONAR to the depth and extent that you are.

NOTES:

For the record, this is how I currently categorize plugins...

Categories of plugins for Sonar x64:

1) Native x64 plugins tested and approved to work with Sonar x64 = Heavenly

2) Native x64 plugins written for and locked exclusively to Cubase x64 = Forgettaboudit

3) x86 plugins tested and approved to work with Sonar x64 BitBridge = Happiness

4) High profile x86 plugins that *should* theoretically work with Sonar x64 BitBridge = Be wary! Test, test, test!

5) x86 plugins that at first glance work with BitBridge, but on further testing, don't = Annoyance, leading to 6-10

6) x86 plugins that don't work with BitBridge but do work with JBridge = Relief

7) x86 plugins that don't work with BitBridge but kinda/sorta work with JBridge = Desperation, but all is not lost... contact Joao...

8) x86 plugins that don't work with BitBridge OR JBridge but are made by active, reputable companies = Hopeful

9) x86 plugins that don't work with any bridge and are made by unresponsive one-developer shops = Sadness and Frustration

10) x86 plugins that are really cool, but don't work in any bridge, and are no longer maintained = Bitter disappointment, prepare for jettison