As my post in WL8 forum did not get a response (Wavelab hangs when pressing play - WaveLab - Steinberg Forums) I’m starting a thread here related to my ongoing issue of Wavelab hanging after I launch it and press Play for the first time. No difference in behaviur between WL8 & WL9. Cubase works flawlesslly as does every other audio app on my PC.
Running Win7 64 bit with latest RME drivers for HDSPe AIO.
Hanging “forever” or only 2 or 3 seconds?
Forever, totally unresponsive. So I have to exit from Task Manager and try again until eventualy it works.
Some diagnostic could help…
Please do this:
Start WaveLab (and do not start playback)
Enable these check boxes:
Run C:\Program Files\Steinberg\WaveLab 9\Tools\Tracer.exe
Now Start Playback. The Tracer window will show some text. Please pass that to me.
Thanks
This is what Tracer reports:
23F4: ////// WaveLab Diagnostics //////
23F4: WaveLab Pro 9.0.15 (build 544)
23F4: Operating System: Windows 7
23F4: ON: Extreme Logging
23F4: ON: Audio streaming
23F4: “Session optimized for CPU: Advanced Vector Extensions instruction set (e9)”
23F4: *** Logging Rules ***
23F4: “Log.AudioStreaming=true”
23F4: “.warning=true"
23F4: ".critical=true”
23F4: “*.debug=false”
23F4: Start of TAbstractBaiosEngine::EnsureAudioDevice
2034: m_deviceManager->countRegisteredDevices → 6
2034: m_deviceManager->getDeviceName / id → ASIO Hammerfall DSP / ASIO Hammerfall DSP
2034: Already registered: “ASIO Hammerfall DSP”
2034: m_deviceManager->getDeviceName / id → Generic Low Latency ASIO Driver / Generic Low Latency ASIO Driver
2034: Device not loaded: “Generic Low Latency ASIO Driver”
2034: m_deviceManager->getDeviceName / id → Guitar Rig Mobile I/O / Guitar Rig Mobile I/O
2034: Will load device: Guitar Rig Mobile I/O / Guitar Rig Mobile I/O
2034: THostApplicationA::getMainWindow → 0x230a88
2034: TStringResult Device not connected.
2034: Loading device FAILED: Guitar Rig Mobile I/O
2034: Device not loaded: “Guitar Rig Mobile I/O”
2034: m_deviceManager->getDeviceName / id → Guitar Rig Session I/O / Guitar Rig Session I/O
2034: Will load device: Guitar Rig Session I/O / Guitar Rig Session I/O
2034: THostApplicationA::getMainWindow → 0x230a88
2034: TStringResult Device not connected.
2034: Loading device FAILED: Guitar Rig Session I/O
2034: Device not loaded: “Guitar Rig Session I/O”
2034: m_deviceManager->getDeviceName / id → Rig Kontrol 3 / Rig Kontrol 3
2034: Will load device: Rig Kontrol 3 / Rig Kontrol 3
2034: THostApplicationA::getMainWindow → 0x230a88
2034: TStringResult Device not connected.
2034: Loading device FAILED: Rig Kontrol 3
2034: Device not loaded: “Rig Kontrol 3”
2034: Will load device: ASIO Hammerfall DSP / ASIO Hammerfall DSP
2034: THostApplicationA::getMainWindow → 0x230a88
2034: Idle handler added (0xab0aff0) Number of handlers: 3
2034: Loaded device: ASIO Hammerfall DSP / ASIO Hammerfall DSP
2034: m_deviceManager->performPortActivations() → 1
23F4: End of “TAbstractBaiosEngine::EnsureAudioDevice”
23F4: Start of Main Thread Breathing After Baios Init
23F4: End of “Main Thread Breathing After Baios Init”
29BC: m_deviceManager->getSampleRate 96000
29BC: TAbstractBaiosEngine::GetSampleRate2: 96000
29BC: Start of “TAbstractBaiosEngine::CanSampleRate: 44100”
2034: m_deviceManager->isSampleRateSupported 44100 → 1
29BC: End of “TAbstractBaiosEngine::CanSampleRate: 44100”
29BC: Start of “TAbstractBaiosEngine::SetSampleRate2: 44100”
2034: will call m_deviceManager->setSampleRate 44100
2034: result → 1
29BC: End of “TAbstractBaiosEngine::SetSampleRate2: 44100”
29BC: m_deviceManager->getSampleRate 44100
29BC: TAbstractBaiosEngine::GetSampleRate2: 44100
29BC: Start of TAbstractBaiosEngine::StartEngine
2034: MESS from Baios: blockSizeChanged
2034: Message → New ASIO block size 1024
2034: m_deviceManager->start() 1
2034: Baios is now STARTED
29BC: End of “TAbstractBaiosEngine::StartEngine”
29BC: m_deviceManager->getBlockSize 1024
29BC: TAbstractBaiosEngine::GetProcessBlockSize: 1024
29BC: buffer size after start1: 1024
23F4: NotifyProblemMaybeDoReset
23F4: Long delay for “StartPlayback” 7000 ms
29BC: Restart took too long
29BC: baios restart waited: 7002
29BC: m_deviceManager->getBlockSize 1024
29BC: TAbstractBaiosEngine::GetProcessBlockSize: 1024
29BC: buffer size after sync: 1024
23F4: MESS from Baios: registeredDeviceArrived
23F4: Message → kMsgRegisteredDeviceArrived
23F4: PlaybackProblemMaybeDoReset
23F4: PlaybackProblemMaybeDoResetEx
Nothing after this, so I have to terminate from Task Manager
Did the above log help at all ?
Not really. But the log shows that the last time you used the audio card (before WaveLab), it was set to 96 kHz. And in WaveLab, you try to play a 44.1 kHz file. Of course this should work, but I am wondering if your problem could be related.
To know, please play any file eg. in Cubase, then quit. Then load the same file in WaveLab, and play it…
Same problem or not?
Yes I agree the problem seems to be related to that. I just opened a 24/44.1 project in Cubase, closed it, then opened Wavelab and played a 24/44.1 file … no problem at all. But if Cubase (or presumably any other app) leaves the soundcard at a different sample rate from the file I want to play in Wavelab, I often get the problem.
When it happens I can see from the RME control panel that the samplerate does get changed by Wavelab when it should be … so I don’t think it’s an RME issue, as the card seems to be doing what it is supposed to.
Sometimes if I refresh the VST connections in Wavelab before I hit play. then I can avoid the problem, but not always.
Thanks, that puts me on the right track.
I cannot believe this is still ongoing 
This is identical to the issues I was seeing in WL8 and 8.5
Play a 44.1khz file - all is well. Then a 96khz file and all is well. And then a 44.1 file immediately after the 96k - instant - and permanent freeze and hang up. So bad that WL has to be killed via Task Manager.
Since no fix was ever made available - I simply do not play 96k files in WL anymore.
Sad part is - 44.1->96->44.1 in Studio One is flawless. the RME switches instantly to the right rate and away we go. So Studio One gets the nod here…
Not sure how this item could be overlooked for so long. Clearly it was never tested with one of the most popular cards/driver sets out ther.
VP
I’m having this issue too, when playing files with different sample rates…
Still have this issue in 9.0.25 … the only improvement is that after xx seconds of hanging Wavelab does at least let me try hitting Play again (or anything else) whereas I had to exit via Task Manager previously. Attached are two tracer files: tracer1 is an example of hanging. tracer2 is hanging, followed by me clicking Refresh under the VST Audio Connections tab, which fixes the issue (until WL restarts).
tracer.zip (2.41 KB)
Hi,
Maybe the audio card is set to external clocking
and that’s why switching between 44.1, 96, 44,1 kHz audio files
doesn’t work?
Fireface set to Internal clock/Master and plackback audio files 44.1 and 96 kHz
Why I’m asking is if I do this here with RME Fireface 800
and check with Fireface settings dialog no problem to switch between sample rates
I see clearly 44.1 to 96 kHz and back with WL 9 and OS X 10.11.6 no crash.
regards S-EH
No, it’s not that: it’s set to Internal. Quite a few people with RME hw have had this issue with WL for a long time, so mine is not an isolated example.
+1. I have not experienced it since I lasted posted on this thread but now as then - I never use WL9 for any playback of files with different sample rates,
And as before - none of this happens in Studio One v3 . Same RME interface, same settings, same everything.
No problem at all mixing files of any sample rate all day long.
Amazing that WL continues to not work correctly with RME cards.
VP
Does Studio One “convert” everything it plays to a certain sample rate? I think it might. In that case, the explanation would probably be that the card does not have to reset itself. WL does not do this AFAIK … and probably shouldn’t.
Not a chance. If that were the case - no one would use the product.
When I play a 44.1 and then a 88.2 - I can see the sample rate changes occurring within the RME control panel.
For now - WL is not capable of playing files back to back with different sample rates when an RME card is in play.
It needs to be addressed.
VP
You’re right - it’s as simple as that, and amazing that it hasn’t been fixed already.
PG hasn’t commented on the trace data I posted to this thread but hopefully it will help get this fixed once and for all.
@vocalpoint From the current Reference Manual for Stud*o One:
Sample Rate
If the sample rates don’t match, Studio One resamples all audio files to match the sample rate of the hardware …
Understood. While I am disappointed with any down-sampling occuring - it does makes total sense now.
Major Update: Because this thread was picking away at me - I did another extensive test with WL9 (9.0.25) just moments ago.
I dragged 4 different FLAC files into an empty audio editor project each having a different sample rates (44/16,44/24,88/24 and 96/24 (this being the top end of my RME card).
I was able to instantly switch between any of these files with zero delay, freeze or halt. This is the first real heavy testing I have done on this since I first posted in this thread back in April.
So I sheepishly take back my skepticism on this. Clearly something has been fixed - at least for me - since April. I could not get this test to work back then and it works perfectly now.
To those still having “hang” issues - this could be environmental (your machine) in nature.
For what it’s worth - my tests this morning were done using RME driver 4.12 - and I know there is a much newer driver out there (4.15) as of this writing.
Cheers!
VP