Hi, I find that Dorico will often freeze and require a force quit [macOS 11.6] if I’m switching between audio apps, and they don’t all agree on the current sample rate.
For instance, I might be working in Pro Tools on a 96k project, and have PianoTeq open, set to the same rate. Later, if I open Dorico, my UAD Apollo 8 interface will duly switch to 48k, which is my default sample rate for Dorico projects. All good so far.
If, however, I reopen PianoTeq (as a standalone) it’s still set to 96k sample rate, and will warn me to open the “Devices” panel where I can then set it to 48k to match Dorico. However, at this point Dorico is frozen, I get the spinning beach ball, and have to force quit Dorico, and the VST Audio Engine to get back to work.
I’d love to have a workflow where audio apps warn me about sample rate mismatches, and allow me to intervene without apps locking up. None of my other audio apps require a force quit in this situation, including Pro Tools, Ozone, iZotope RX, Logic, etc.
Hm, strange. Normally Dorico should follow, even if the sample rate gets changed externally.
I’ve just tried myself with Pianoteq-Standalone, where I change the sample rate in Pianoteq and Dorico just follows gracefully.
Your diagnostics report does not give much hint either. There are no no crash dumps at all, just one process sample of the audio engine, but that was during the start of Dorico at 12:18. In the Dorico log I can then see that at 13:04:28 the sample rate was changed externally, after that the log stops. I guess you killed Dorico , right?
But in the logs I can also see that at 13:04:20 an AutoSave is executed. Maybe that is the problem. Dorico gathering the project state from the audio engine and the sample rate change at the same time could bring the system into trouble.
Do you always get that behaviour or only sometimes? Could you please reproduce again and send a new diagnostics report straight after? Thanks very much.
Well, I tried to retrace my steps, and everything is working for the moment.
I guess it probably doesn’t happen all the time, but frequently enough that I’m always a bit worried as I’m bouncing between projects with different sample rates.
Pro Tools doesn’t lock up if I change the sample rate of the apollo interface, but does show a warning dialog:
I’ll continue working today, and see if I can trigger a hang, then will send the diag report.
I have a similar issue. Logic Pro prefers to set the sample rate to 44100 and then the specified sample rate (48kHz) immediately everytime creating a new project. This always crashes my Dorico running at 48kHz.
Hi Scott,
thanks for the new data. Contained are 3 crash dumps of the audio engine with following dates:
27th Sep 13:40; 28th Sep 9:59; 28th Sep 18:22
But all crashes point to 3rd party plug-ins. The first two crashes were in audiomodeling.SWAMTrumpet and the other one in Arturia.Analog-Lab-V.
So I guess theses crashes are unrelated to the sample rate issue. Please watch out further.
Hi ShikiSuen,
could you please be more precise, I don’t understand what is exactly set when and where. And, what do you mean with specified sample rate?
Furthermore, if you can reproduce the crash situation so consistently, please do it again, then restart Dorico, choose ‘Help > Create Diagnostics Report’ and post the corresponding zip file here. I’m really keen to see the data. Thanks
I’ll do if I can repeat this issue with the incoming release of Dorico 4. Right now I am busy relocalizing the Simplified Chinese UI of Dorico 3.5 from scratch (because the official one is lingualogically horrible… fixing translation error one-by-one won’t work), and I need to figure out how to reuse the localization resources once Dorico 4 cames out.
At this moment I think it is Logic Pro’s curious habit to force-switch the system audio sample rate to 44100Hz (and back to user-specified sample rate again).
Ok, Dorico locked up again while trying to change the audio device. Here are the steps I took, and I’ve attached the Diagnostic Report.
Start Dorico without the UA Apollo Interface powered up - Dorico device defaults to “Built-in Audio” 44100
Power up UA Interface (In Device Setup, Dorico doesn’t list the UA device as an available choice, so…)
Quit Dorico
Restart Dorico
Device Setup shows “Built-in Audio” 44100 as selected device (now the UA device appears in the list as an available device)
In the “ASIO Driver” drop-down, select Universal Audio device - UA device’s clock temporarily switches from 48k sample rate to 44,1, then switches back
Dorico’s Device Setup remains on “Built-in Audio” and Dorico becomes unresponsive, Activity Monitor shows “Dorico (Not Responding)"
Have to Force Quit Dorico (VST Audio Engine still running in Activity Monitor)
There are a couple of VST Audio Engine crashes in the diagnostics you’ve uploaded, which appear to be caused by the SWAM Alto Sax plug-in – you may want to try either updating that plug-in, or sending the crash reports to the team at SWAM so they can investigate, or check to see whether a more recent version of that plug-in is available.
Thanks Daniel, Audio Modeling just released v.3 of their SWAM Woodwinds (including the Alto Sax), and I updated them yesterday; I then replaced them in the project in question, and removed them from the Allowed VST plugins list (and I just reconfirmed that only the v3 woodwinds are in that list); unfortunately this issue happened today. I’ll check in with Audio Modeling.
I also noticed someone else mentioned they were running PianoTeq at the same time when they had a sample-rate related crash, and I was today as well (v7.42)… Wonder if that might be a cause of the problem?
Hi falhousen,
but in your case the application only deadlocks and not crashes, so I don’t think it has to do with Pianoteq. But please do the same recipe again, and when Dorico then deadlocks, please open Activity Monitor and create a spindump and post that one here. In order to do so, the Activity Monitor has at the top middle, left of where it says “CPU”, a little icon with 3 dots. Click on that and a pop-up menu appears. Choose the Spindump item and follow the instructions. Thanks
I found that if I don’t load a file into Dorico, the clock problem doesn’t occur. When I loaded a file (with VIs) the problem happened again. I’m attaching the spindump.
Thanks for the spindump. You have a pretty complex setup in that there are literally hundreds of threads running in parallel in the audio engine and I can’t really say who is responsible for the deadlock. It could be Pianoteq, but I’m not sure.
I don’t want to appear lazy and put off the work on your side, but could you please create variations of your project where you selectively leave out single instruments and then try again? So first e.g. take the project and delete Pianoteq from it, save as and then do the whole thing again. Next then delete only SWAMTrumpet and so on. I hope you get the point. Thank you very much.
It looks like I can trigger the deadlock by trying to switch the ASIO Driver from “Built-in Audio” to “Universal Audio Thunderbolt” before all VIs have finished loading.
If I wait to switch the ASIO driver until the VIs have completely loaded (which I’m judging by the fact that the transport functions, and all instruments sound when I hit the spacebar), I don’t get a lockup.
The sample rate doesn’t seem to be the problem, but rather switching the Audio Device before everything’s loaded up; I can subsequently switch the sample rate with no problem.
Simple solution, and makes sense to me–Some VIs don’t seem to like the clock/audio routing being switched until they’re in a stable state?
