wdl-ol
wdl-ol copied to clipboard
olilarkin
[Standalone] Windows DS/ASIO audio config buggy
When changing the audio driver settings in the standalone preferences on windows, the .exe will often hang when switching from DS to ASIO
Actually this seems to have something to do with my audio interface setup / virtual box. When my MOTU 828 is not connected in OSX I can change the DS/ASIO config in my VM fine. If anyone else has problems, please let me know.
Similar problem here, standalone build hangs when changing IO Vector Size. Currently 64 and can't change it back. Using VS2013 Express. Please note I'm a rookie (care to tell me how to reset settings?)
Standalone version stops working (hangs) in DirectSound mode when I click the "Apply" button in File>Preferences. I've found out that the program hangs when it reaches the following string (RtAudio.cpp): WaitForSingleObject( (HANDLE) stream_.callbackInfo.thread, INFINITE ); I didn't change anything in the IPlugEffect example. I use Windows 7 x64 and Visual Studio 2010.
I have what seems like this problem as well, specifically when compiling for 64-bit. Whenever I change the input device or the sample rate in preferences, the exe hangs. Changing the output device seems to work fine.
When debugging, I can see that I get stuck in the loop between lines 4714 and 4712 of RtAudio.cpp. Specifically, leadPointer never changes. (In fact, none of the variables change).
I'm wondering if this is because of an old version of the ASIO SDK bundled with RtAudio. RtAudio comes with ASIO SDK 2.1, while the most current version is 2.3. In the changelog for 2.3 (downloaded from the steinberg website) it says (cut to just the important part):
Changes in ASIO 2.2 since ASIO 2.1
- added support for Windows 64 bit
I'll try this later on and see if it fixes anything.
(I am also having an issue with the Steinberg VST3 Test Host where the GUI for my VST3 does not show up, and clicking the info button in the test host results in it trying to access memory location 0x0000 and crashing. Hoping it's related as well...)
I'm experiencing this at the moment, and there are a couple of potential issues I can see.
The first is that the 'buffer->Lock' call on line 446 of RtAudio.cpp in stopStream() is sometimes failing with an invalid parameter, not sure why.
The second is that both the MainThread and the callback thread are free to read and write stream_.state and there doesn't appear to be any mutex or lock involved there. This implies that it's possible to stop the streaming (via RtApiDs :: stopStream()) in the main thread when the callback thread is in the while(true) loop, where it could get stuck forever waiting for the pointer to advance on a buffer that's not playing.
FWIW, updating to RtAudio 5.0.0 fixed this for me. I also updated to RtMidi 3.0.0. Doing so required making changes in app_main.cpp due to RtError becoming RtAudioError and RtMidiError.
