When I export audio and anything happens: I unplug my headphones e.g. Audio export stops ans sometimes Dorico crashes. This is since 6.2
I’m sure the development team would appreciate a copy of your diagnostics being uploaded here (Help → Create Diagnostic Report).
Dorico Diagnostics.zip (815.9 KB)
In general, audio has always been very buggy. When changing devices, I always have to open the device control panel to check the boxes for output. This was also the case with Cubase when I used that. Now I switched to Ableton I have no problems whatsoever. So this would most likely not be a Dorico problem but a Steinberg problem. And this is going on for years now. Updating still is a very painful process. I’m wondering if Dorico wouldn’t be better off without Steinberg.
Are you sure it’s not a problem with the drivers for your audio hardware? I’ve rarely had audio crashes on MacOS.
1 Like
Absolutely sure. Only Steinberg products crash all the time…
What if you change the device in Dorico to be built-in speaker, restart Dorico if sample rate has been changed, then export the audio?
That works. For one time. If I want to export audio, I must not touch this. As soon as something changes in the audio chain, exporting becomes impossible. The way to go now is: restart Dorico, open project, export audio. Every time. I can’t imagine it to be ‘normal’ having to walk on eggs when handling audio. Therefore I think this is a bug. (Apart from the autistic way Steinberg handels audio routing in general).
Hi @RoelVanWijk, thanks for the data.
I will take a closer look on Tuesday when I’m back to the office. A little patience please. Thanks
1 Like
What VSTs are you using? If sample rates are changed (due to change of audio devices), Kontakt 8 would prompt a warning saying the audio would malfunction until a restart. Some other VSTs might have no warning message, but they would malfunction too.
Thanks y’all!
I’m using only NotePerformer, newest update 5.1.2
Hi @RoelVanWijk , included in your diagnostics is a crash file of the audio engine, which shows the underlying problem. When things like audio devices changes happen, internal callback routines will get invoked and processed further. When this happens during an audio export our code is not prepared for this to happen and thus crashes. I’ve entered the case into our bug database and we will work on it. Thanks for reporting.
Until then the work around quite obviously is to avoid doing anything while export is in progress.
Wauw, thanks!
I understand it was always that way? I obviously never felt the urge to remove my headphones while exporting. The workaround is very doable, thanks!
1 Like