WL keeps losing Audio Connections

Just had this happening here a couple of times on different occasions, maybe 3-4 hours after starting up Wavelab. WL8.5.2 on Windows 8 with a Lynx Two-B card. The last time Wavelab woudn´t restart after shutting the program down, so I had to reboot the PC. Never been an issue Before.

Best Regards

WYCA … I wonder if you are describing the same ‘condition’ recently discussed here:


My DAW seems to behave a bit different, but maybe it´s the same basic problem? The ASIO connection for me has Always been lost after using Wavelab for a while. Everything is is ok at boot up, but when I lost ASIO Connection it was when switching between different wav:s. Trying to refresh ASIO didn´t help. When I shut down Wavelab and tried a restart, nothing happened, because Wavelab was still running according to the task manager. So I had to shut that process down Before Wavelab started again - and after the reboot, ASIO connection was back!

I checked the wav:s I was working on when this happened (again today), and actually one of the files I was switching between was 48kHz, and the others 44,1kHz. I´m not sure if Wavelab tried to switch samplerate when I´ve lost ASIO Connection, but I wouldn´t rule that out - thus, it may be the same basic problem.

[EDIT: I can now confirm that it is when switching between wav:s with different fs that the ASIO connection is lost]

Nice to see PG responding in the other thread! Hope there is a fix soon.

Best Regards

Yes, appears to be the same symptom… still “enjoying” the daily exercise of driver-refreshing…

Hmmm … WYCA on our system the RME (AIO) will allow WL to play again after a short while. No refresh is required. Also, on the other thread, I made the observation that I had reason to suspect that this issue is more to do with the RME card/driver. The reason is that in my system, the RME send AES to Mytek converters. I notice that the lights on the Mytek are lit, but frozen, as though it was receiving AES from the RME but WL appeared to be ‘hanging’. This might not be immediately obvious unless you are sending AES to an external converter. I think in your systems you also send AES as well? Good luck.

I get this about every second day but ALWAYS when I load a file that has a different sample rate than the one previously loaded. Example - I have a 44.1/16 bit file in the editor and then open a 24/96 file. WL completely dies and no amount of pressing, prodding or clicking will get it to actually start. Have to kill the entire session.

Bloody annoying.

(Sidenote - before anyone chimes in to say “click this in Options or Click that under VST connections” - trust me when I say - I have clicked everything that is possible to click with no success)

But - if I load up Studio One Pro on the same computer with the same RME Multiface - I can load and play files of all different sample rates and bit depths all day long without the slightest hint of any issues. Same for iZotope RX4.

Since RME and Steinberg reside in the same country and presumably have good working relationship - it surprises me (and disappoints) that they cannot get their collective heads together and get a working layout.

Given Wavelabs “professional” status - you would think it would be one of the major apps that would have no issues like this.


Did this problem just start with Wavelab 8.5? We’re still running WL 8.0.4 and have never had this problem with RME or Lynx.

I am on 8.5 - but honestly can’t remember if it was an issue back in the 8.04 days. Big difference too in this equation are the latest v4 RME drivers (currently @ 4.06) that most certainly will have a bit of an effect on things.

Personally tho - I am starting to doubt Wavelabs stability overall as it seems to be the only pro level app out there that consistently won’t play nice with standard vendor plugins (Piles of threads on that topic in here) and this ongoing saga with RME.

Almost seems like WL has it’s own “non standard” methods to talk to industry standard plugins and drivers- which in turn fail when you really need it to work.

With something like Studio One over here - I honestly have never actually seen a glitch, slowdown, hesitation or anything else using the same plugins and audio interface that is available to WL.

So whatever Presonus is doing in their app - maybe they can share some of that magic with PG and get WL back to stable.


Bruce is right about the plug-in issues. It’s kind of a double whammy since VST is pretty much a Steinberg-only thing nowadays (at least on macs), and doubles my maintenance chores (triples if I count PT, but I don’t really!). When they don’t work it makes the format issue worse.

I think it was better in 8.04, but that could be relative to soundBlade. Circa 8.01-03 I rarely used sB at all, but since 8.5 I’ve frequently used sB over WL due to better plug-in handling. It probably helps that it runs both AU and VST, so when there’s a problem you can just use whichever is working. WL can’t do that, so it gets blamed when the VST is munged, whomevers fault it may be.

Bruce and Daved, I feel for you about the plugins. We’ve been very lucky to have virtually no issues at all with what we’ve been using with Wavelab since Wavelab 6: UAD, Waves, Sonnox, TC. (except an early issue with Waves transparent display I solved by swapping out the video card to another manufacturer).
I’ve wondered through all the discussions why so many people say every third party plugin they use works fine in Cubase, Reaper, Studio One, Pro Tools, Logic, etc., and I always got the feeling maybe, just maybe, those programs were possibly more tolerant about parameters and behavior they were willing to accept from a plugin that wasn’t strictly by the book. And that Wavelab was much more strict in it’s requirements. I don’t really know what I’m talking about, and someone can tell me that has nothing to do with it, but I always got that feeling.

Ha … the grass is always greener. Except we know that it usually isn’t when you’re there (first big crash after set up of a new ProFools system).

My gut says it’s the other way around - WL uses some substandard oddball way of loading/using/talking to industry standard plugs and the other guys do it right.

The never ending graphics issues with plugins in WL etc etc have been happening for a long while. In the past I have even spoke to developers of specific plugs I use - like WaveArts for example - and even they say that WL has a very strange plugin pipeline and that it’s one of the only apps to consistently kick out errors and issues.

Honestly - it blows my mind that a supposedly “Steinberg” product - whose development team should have access to most detailed VST specs and standards possible (Since Steinberg invented VST) - end up being the one app out there that barfs on plugins (and now audio drivers) the most?

It begs the question - does PG ever trade notes with the Cubase or Nuendo devs? Why is it that Nuendo is rock solid in the plugin and driver department and clunky ole WL is left bringing up the rear?

Seems to me that all three apps FROM Steinberg (Nuendo, Cubase AND Wavelab) - should all use the same identical code to load and use VST plugins correctly.



Maybe they might have exaggerated just a touch there …

Their words - not mine :slight_smile:

But hey - the forum here speaks for itself. Not exactly a secret that WL has its own share of issues…


Sometimes it behaves as you described. But mostly when WL is put into play, its tranport and meters freeze and no sound. We have to wait until it snaps out of it. Hit play again - freeze again. Wait till it snaps out of it (maybe like 30sec). Refresh reliably solves the problem. As others have mentioned, I believe it is correlated with a change of Fs as I can see the RME control panel indicates it “wants” to be one sample rate, but has not physically made the switch. Will try to get a screen shot next time it happens.

Yes, AES.

Luck?!? Ha,ha, ha… would rather have the engineered solution from WL and/or RME.

There are lots of bugs in this version of WL. Bugs which effect some rather essential/fundamental procedures and are alarming. None the less, WL is an outstanding program for mastering and I believe PG will sort them out. I STRONGLY encourage PG to not wait too long.

This is what happens here to the letter.


Totally agree. I still think that Wavelab might have more stringent rules for plugins than other apps do as part of the problem, but your call for identical code would take care of that anyway. My original thought of Wavelab difference came from the problem with Ozone, where Ozone was out of spec:
and PG said he could adjust on the Wavelab side (“the problem is on the Ozone side (the plugin’s view coordinate is out of the window). Fortunatly, I have found a way to fix it on the WaveLab side”. But Ozone probably displayed fine in Cubase, Reaper, etc, even with the out of spec view coordinate. Just made me think all the other programs might be allowing say 70mm if a spec says 50mm (or whatever unit of measurement), giving leeway, but Wavelab is not allowing any leeway. But like you said identical code would cover that, and if other programs are allowing leeway, Wavelab should too. Could be wrong, but it made sense to me at the time.

Sorry to derail this Audio Interface thread. Still no RME problem here with Wavelab 8.0.4, but I’ll try 8.5 soon to see if the problem pops up.

of course I’m making wild uninformed guesses about leeway that may or may not be true, but I’d love to be corrected with the correct information.

I think you’re right Bob. It’s been my impression in the past too, that WL is very strict in interpreting the VST standard (or adhering to the standard at all), where several plugin companies don’t take things so strictly and have no problems doing so in other DAWs that are also more lenient - including Steinberg’s own Cubase.

But there’s also the rendering approach in WL, where a copy of a plugin is taken for rendering. This also doesn’t always play nice with plugin companies’ expectations in plugin behaviour.

But whatever the causes of problems, hopefully a working solution can be found. I myself have been lucky so far, I guess, but then I also don’t use very many 3rd party plugins…

WYCA … One further thing: I have noticed that this seems to happen when I play … for the first time in a session … a file that I might have loaded up from a different drive to the session drive. Typically, a reference file at 16/44.1 that lives on another drive. So, when I switch from a session file at say 24/48 to listen to the reference file, that’s when the RME typically hangs. But I can’t reliably reproduce this. Also, once this ‘happens’ the system seems fine for the rest of the day.

So, I wonder if the different drives are a contributing factor.

If I discover any other clues I will share them. You don’t have any easy job with all those systems.