Tenfoot Posted 9 hours ago Share Posted 9 hours ago I thought I would start a new thread for this as the old one is marked as solved, and it really isn't. This is a continuing issue with Sonar. As described in the older thread it crashes upon attempted opening once any ASIO device is selected in VB audio matrix as Sonars device. The only way to restore functionality is to uninstall VB matrix. Simply deleting aud.ini does not work. Using wasapi shared in Sonar and VB matrix works fine. Strange and disappointing, as I also use Reaper, Cubase and Studio One, all of which work perfectly well with VB matrix ASIO virtual devices. If anyone has found a solution I would love to hear:) Link to comment Share on other sites More sharing options...
azslow3 Posted 3 hours ago Share Posted 3 hours ago 4 hours ago, Tenfoot said: ... it crashes upon attempted opening once any ASIO device is selected in VB audio matrix as Sonars device ... I can't understand the meaning of that statement. Sonar definitively can work with VB-Audio Matrix (I have never tried Coconut, but seriously... if someone needs Coconut, it is time to invest into proper gear...). Just to be sure, I have tried all combinations. So ASIO /WASAPI. With Matrix loaded and not loaded (obviously IO selection in Sonar has to be changed to get sound). But as with any VB staff, the user has to understand what this software and many of its settings are doing. Windows Audio settings are important as well, especially when audio drivers for hardware audio interface have "not the best quality". VB programs tend to glitch/stuck if something is configured wrong (or by starting programs in wrong sequence). The only Sonar specific I know, it tries to auto-open devices "early". The settings are scattered across several Preferences pages, it is not possible select complete target configuration (driver model + IO channels + clock source) and only then load it. Once ASIO is selected and applied, Sonar already tries to work with some (f.e. last used in ASIO mode) device/channels. And by default Sonar enables all channels. As the consequence, when default/current Sonar ASIO configuration is not only "wrong", but also stuck/crash (easy to achieve with VB and many "well known" devices), that is not easy to correct. General strategy is: make Sonar work in particular driver mode, let say ASIO. If uninstalling VB Matrix is required, fine (doesn't take long to re-install). But just disabling ASIO device in Matrix can be sufficient. If uninstalling is the only route: change ASIO configuration in Sonar to something which should work after required change. F.e. don't use audio interface which will be under VB control. There are plenty of "virtual" devices, from VB and other software, which can be used at that stage. re-install drivers (VB Matrix). check Sonar is still ok properly configure Matrix/Windows/everything else working with audio attempt to select Matrix ASIO device in Sonar. Most important: don't let any software except VB Matrix use real audio interface(s). That includes Windows/OBS/Sonar/etc. Especially important if real device driver is unable to work in ASIO and WDM in parallel. That should be easy to do after you install VB Matrix but before you configure any ASIO (real) audio interface in it. Just switch Windows/OBS/Sonar to use Matrix virtual devices. let audio interface be the clock master in Matrix (if possible) everything should be configured to work with the same sample rate. When some not primary WDM device simply can't work with desired sample rate (f.e. webcam), that is usually not a problem. But Matrix/Device/Windows/Sonar in different sample rate is looking for troubles. The only tricky software is Sonar, sample rate is project dependent. I will say: if you have projects with different sample rate, use dedicated audio interface for Sonar. Can be combined with external analog audio looping when required. Note that Matrix ASIO sample rate is locked to master. So if you still consider to use different sample rates in Sonar, you will need more then one Matrix configuration. Use audio interface as master with different sample rates or use Matrix Clock as master with different sample rates while keeping audio interface under the same sample rate (if that works better). use pessimistic buffer settings (start at least with 512). VB solution is not going to have low latency. It put extra processing and synchronization into audio chain. Any underrun can produce problems in range from glitches up to total crash, even when in "direct" mode it just produce small pop. 1 Link to comment Share on other sites More sharing options...
Tenfoot Posted 59 minutes ago Author Share Posted 59 minutes ago Hey Azslow3. Thanks for the detailed response! I have used Sonar for a very long time and am also very familiar with how VB Audio Matrix works. I do use the Coconut variety, as it seems does everyone in the other thread reporting issues, including a Cakewalk staff member who concluded that using a driver other than ASIO was the solution, so Coconut may be the problem. Since you had gone to so much trouble to respond and I know you have a lot of experience and knowledge with windows audio, I did return to my studio to give your suggestions a try. Here is what happened: 1. VB Audio Matrix is set up with my RME Fireface as clock master, and all virtual devices set to slave to it with the same sample rate. This is how I have always run it. 2. Sonar was set up and running with Audio Matrix with its driver mode set to shared WASAPI utilising one of VB matrix VAIO devices without any issues. 3. All other audio software was set up and able to run using VB Matrix virtual ASIO devices. 4. With only Sonar and VB Audio Matrix running, I set a new virtual ASIO device active in DB Audio Matrix. I then went to Sonars settings, and changed the driver mode from WASAPI to ASIO. As soon as I did this, Sonar began to scan the available devices and immediately crashed. Once this happens, Sonar can't be re-opened. It gets as far as the splash screen then closes. This is the behaviour I described in my first post that you mentioned you didn't understand my statement. I have been down the uninstall/re-install/delete AUD.ini path many times trouble shooting this issue. Again tonight, only uninstalling VB Audio Matrix allowed Sonar to open again, upon which it defaulted to the RME ASIO drivers. If I don't change the driver mode in Sonar to something other than ASIO before reinstalling VB Audio Matrix, Sonar will again not get past the splash screen after. I use Macrium Reflect to restore my system to a optimal condition so do not mind experimenting. I think I have tried most everything!It seems the issue lies between VB Audio Matrix Coconut and Sonar. I have reproduced this issue on 2 other computers as well, all running Windows 11. Sonar is no longer my main DAW, and I only have to use it on the rare occasion that a client has started a project and I need to port that project to Reaper, Studio One or Cubase, so I can get by with WASAPI drivers. It would be nice to have ASIO back though:) You mentioned that you can't expect low latency with DB Matrix. On the contrary, I run my whole studio through DB Matrix with a safe general setting of 128smp with zero issues outside of Cakewalk. It seems the problem lies somewhere between Sonar and VB Coconut. It is surprising, as I have found both to be very stable otherwise. Thanks again for chiming in! Kind regards, Bruce. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now