I’m working on a large project - 4 movements, 45 players (holding 62 total instruments), and playback is getting increasingly worse-behaved as the orchestration has expanded. I I’ve seen other posts about editing slowing down, but that’s been workable thus far, it’s just playback that’s been a big issue. I’m experiencing at least four separate issues:
When I start playback, the playhead will go for a second or two before audio starts (at the eventual location of the playhead)
When I hit p (for “play from selection”), it is very unreliable about doing as it’s supposed to. I’d say about 75% of the time it will play from wherever it last stopped, and I have to just keep hitting p until I get lucky
When I listen to spots with a lot of instruments playing a lot of notes (such as large swaths of woodwind runs), playback may just cut out. (if any instructions, like strings going from pizz to arco, happen during the cut out, they will not be heeded for the rest of playback)
Most bizarrely: when I export audio to an mp3 file, it’s sped up by about 10% - a movement that lasts 189 seconds was rendered such that it took about 172. There seem to be artifacts in the audio as well. This did not occur while working on the first two movements and has only started happening as I expanded the orchestration further. If I export to .wav, the export is fine.
Do you know why any of this would be happening, or anything I could do to optimize playback behavior? I’ve tried clearing and resetting playback template to default, no luck. The combination of all these issues (particularly the first 2) is becoming quite irritating for my workflow.
If it’s useful for reference, my PC has 32G RAM and an AMD Ryzen 5 3600 processor - not top of the line, but well above the cheap old laptop I’ve been able to run small projects on. Task manager never shows either at concerning usage levels, so it’s not obvious to me that either is a bottleneck here.
And regarding point 4, well, I think that could be a bug. During MP3 export we always use the high quality mode of the encoder. With that mode switched on, the encoder may use a different sample rate than was specified; why and how can be read in the official MP3 documents from the Fraunhofer Institut, the inventors of that format.
So my guess here is, that the encoder changes the sample without this information getting fed back to the audio hardware, therefore the mismatch of sampling rates and the wrong audio
I’m not sure how to answer the sample question - I’m using the defaults for everything, so iconica sketch? But there are saxophones and piano and precision in there and I think those draw from other sample sources?
Sorry for the delay on this - I wasn’t initially comfortable sharing the project, but I can share this pared down version of it. I had to put on the silence playback template to get under the 4MB upload size, but (for me at least) if I change the playback template to auto, I can reproduce bugs 1 and 2 above. Note that it may take a few tries to make 2 occur. Is anyone else able to try this out?
Hi @dfloob22 ,
okay, that’s what we wanted to know, so you only used the sounds that come with Dorico, right?
There are also some heavy weight external sound libraries that one can use also in Dorico, could have been that you use such.
But anyway, thanks for the project file.. If I load it and reapply the default playback template then it loads nicely and also plays fine for me.
Some more questions, what sound driver and device do you use. Do you use a built-in sound chip like Realtek or do you have an external audio interface? At what sample rate and buffer size do you run the driver?
Then there are some settings in HALion that I want you to check. If you open the HALion Sonic editor window and there go to the Options tab (red circled)
What are your settings for MaxVoices and MaxCPU, as well as Multi-Core? Do you get better results if you fiddle around with those settings, maybe also with the max Preload?
Note, these options are global and are valid for any open HALion Sonic instance.
Aha! This led to the solution. To answer your first question, though, I’m using the built-in sound chip, 48000hz/24 bit. I think that’s all still at defaults but I’m not sure.
The only things that have changed are that I moved max preload from ~4000MB to ~16000MB, and shifted the balance slider all the way towards RAM (either of these alone was not enough, nor was turning on multi core). I noticed that once I made those changes, VSTAudioEngine’s RAM use in task manager went from ~4000MB to where it’s at now, ~6000MB. With these settings, I no longer experience 1 or 2 from my list of issues.
For 3: I still get audio drop out in one particularly dense moment in the score, though there is less dropout time than before, and the string pizz→arco switch properly occurs now. If I turn on multi core to any non-off value, this goes away entirely, but I go back to having the delayed audio start from issue 1.
For 4: this bug still occurs.
At any rate, I’m marking this resolved - 3 is minor and almost certainly something that would be fixed with better hardware at this point, and 4 is very minor for my purposes (how much you at Dorico care about fixing that, if it indeed is a bug, is your priority). Thanks for the help!
Good to hear that you found settings that work for you.
For 3: You maybe could adjust the Max Voices and increases that value a little and see if that mitigates the problem. If you think that 512 voices is a lot, then yes, it is a lot, but many sounds are constructed by layering several voices. Given the fact that one HALion instance can produce 16 different sounds at the same time and each can be played in a polyphonic way and then one sound with multi layered voices. You see, that easily multiplies and might bring you to the limit in dense passages.
For 4: It’s interesting that no one so far has brought this issue forward. It won’t be high priority, but I will follow up on it.
