Recently I upgraded my PC from a dual RME MADI FX to a dual RME Aox-D system. But I use Wavelab 13.0.10 with my RME UFX III.
Previously Wavelab took ages to start up. I suspect because of the many channels the Madi FX setup has. Now Wavelab takes even longer to fully start up. It even has more channels to be scanned. It seems to be an exponential problem.
I do hope Steinberg will look into this since waiting for minutes on an end is unsustainable for my work. In the mean time I’m using Audacity to edit my masters.
WaveLab does not scan any Audio device while being launched, unless you start with the Startup Assistant and you have the audio device scanning enabled (this is ON by default, but you can hide the panel, and at next launch you won’t have a scan).
Without the startup assistant with device scanning, the first access is when you start playback or record.
This being said, I have a RME UFX+ and the access is very fast. Hence, I think the problem is not where you think it is.
I’ve created a support ticket so it will be looked at.
It took a good 30+ minutes for the startup screen to pop up. I’ve now selected the UFXIII but when I change the channels it again takes ages. So there is something in Wavelab that doesn’t take into account that my system has many channels. I’m not against having a slow configuration. But starting up the program and using it shouldn’t take 30+ minutes every time.
Cubase doesn’t have these issues. Other DAW either.
Didn’t know you could bypass the Startup Assistant. But with it bypassed it did startup normally. It’s a workaround, but it doesn’t allow me to choose my project type. It’s the best workaround thusfar. That is really nice.
When I choose the audio options in the settings it takes roughly 17 minutes to get processed. And every change of audio interfacing will take another 17 minutes. And since I have all my mastering gear hooked up to the Aox-D interfaces it will quite a bit of time to configure that as external effects.
I guess when you are hitting the boundaries of computer audio you’ll run into edge-cases the developers didn’t know existed.
Like I mentioned before. I have a strong believe it is related to the amount of channels for the selected ASIO device. Previously on the dual Madi FX the time I had to wait around 30 seconds. I went from 768 channels to 2048 channels and now the time takes about 17 minutes. This very much looks like an exponential problem to me. I could be wrong ofc.
Wavelab is the only audio program who has this issue. (With the exeception of SoundForge which wouldn’t start at all) Cubase works fine. I had to work with Bitwig for getting that to work with a dual RME setup. Because RME uses a proprietairy way to implement their ASIO drivers.
Currently for the Aox-D I’m using beta drivers because I had issues with my system. And RME provided me with those drivers which aren’t officially released yet. They have been working fine thusfar with Cubase and Bitwig. Besides a few side issues that are related to Dante (which I’m not using atm).
The channels are for the Madi and later on Dante connectivity. So no need for any patchbays when all hardware directly is connected.
I haven’t contacted RME since I don’t believe it has anything to do with their drivers. Besides the behavior of Wavelab 13 with two RME type of interfaces points to a N+1 issue.
Using a 2 channel RME card here but WL seems to be taking longer and longer to load in WL13. Yesterday it took 1.5 minutes to open the first time I opened WL. Any idea of what is going on???
It is not related to problems with plugins. Because when I bypassed the interface check WL13 starts up as you would expect.
But when I go into the audio connections configuration every change I made to the audio configuration will take 17 minutes. In the mean time WL13 does some background task and Windows thinks the application is not responding. So there is some functionality related to checking audio connections that seems to have an issue that scales logrithmically related to the amount of IO of your interface(s). RME seems to use implement the ASIO drivers for their interfaces similar to aggrevated devices on the Mac where the system sees the combination of interfaces as one abstract interface. So with 2048 IO the issues becomes very apparent.
It also seems that this same scanning functionality is used on the default startup screen you get after a fresh WL13 install.
If need be I can make a video of this behavior. Allthough I don’t think it’s constructive to watch 17 minutes to an unresponsive application.
Given the feedback I have, RME is the most used hardware by WaveLab users. This means there should be thousands of WaveLab RME users. I use myself RME hardware daily. @JeeJee mentioned earlier in this thread that he is using the same RME hardware as you, without trouble. This is why there must be an extra parameter on your system that causes trouble. But this is not under the WaveLab control.
RME AES cards as well as RME ADI-2 Pro FS, ADI-2/4 Pro SE, and Babyface Pro FS all working great here with WaveLab for years, as well as the Grace m900.
Like I explained in my first post. I’ve stumbled on an edge-case that is related into using a dual RME Madi FX setup and dual RME Aox-D setup. So I have to use the UFXIII (which I’m using as a monitor controller) in order to be able use WL13 at all. But I can’t use the Aox-D with all my mastering hardware connected to because configuring external effects will take hours configuring because with every mouseclick I have to wait 17 minutes.
The claim that it is not under Wavelab control doesn’t hold ground if you exactly know what is going on. On DAW like Cubase, Bitwig or Ableton my dual Aox-D works fine. Same goes for standalone plugins like e.g. Pianoteq.
Today I’ve installed the latest RME Aox-D drivers and had another go at trying to use WL13 but the problem as I described still exists. I’ve had my fair share of encounters with companies pointing at eachtother with interfacing issues and may have become cynical about it. I do hope this issue will be solved in a sensible way.
