On my mid-2016 MacBook Pro with plenty of memory, playback is pretty laggy. Sometimes it stops before the end of the flow. The playback bar doesn’t keep up with the playback, so watching it isn’t helpful.
I also can’t find a way to send output to anything other than the default built-in audio, even though my speakers are connected to a USB Audio source.
Is there anything I can do about any of these issues? Thanks! – Ken
Could you please choose from the main menu Help > Create Diagnostics Report. That will create a zip file on your desktop, then please send to u dot stoermer at steinberg dot de.
Done. But will diagnostics explain why I can’t select anything but built-in audio for output? Seems odd…
Hi Ken,
thanks for the data, I had a quick look. There is something strange about your system.
When enumerating audio devices the audio engine only detects:
=>Built-in Audio;Built-in Audio
=>Instant On Sound Effects;Instant On Sound Effects
One time it also tried to set the current device to
OWC Thunderbolt 3 Audio Device
but then immediately set it back to Built-in Audio.
This is strrange, because the thunderbolt device did not get enumerated in first place.
I don’t know that device, is there an ASIO driver available for it?
Also, later in the log file I can see many many ‘overload detected’ messages.
These messages come from the audio engine when it detects that it has more
audio data produced than the audio driver can actually shuffle to the outside.
So it is no wonder that you experience that quirky audio result.
As to why that happens, I can not say at this stage.
You are running at a buffer size of 256 samples. How about if you go to Edit > Device Setup,
then choose Device Control Panel and change the buffer size to a higher value?
Does it get any better?
I need to discuss on Monday with other engineers, especially the Mac specialists
and see with what other suggestions they come up with.
Ulf,
Do you think that changing those Buffer Size settings might also help with the Playback Head bug, please; or could be otherwise relevant to it - even though Ken’s case, from your look at hi system - doesn’t seem to be exhibiting it?
I don’t think this would have any impact on it, though you are welcome to try it out. As far as we’re able to tell, the play head bug appears to be a low level issue in the Qt framework where window repaint messages are not being processed. It’s possible that a small buffer size may result in a higher frequency of paint requests, so give it a go.
Thanks so much, Paul; it was 256 - so have set to 1,024.
I’ll leave it that way for a time to see if it makes any difference. Although given the random nature, it might be hard to see if there really is any cause and effect.
Thanks for persevering with this - and good luck!
No go. Just launched Dorico after almost 24 hours. Buffers still at 1024. Wrote a couple of bars and started playing (NUM + . > Space) in Write mode. Froze immediately.
This is a real head-scratcher - though we can reproduce the problem intermittently we haven’t seen it go wrong as soon as playback starts. When I see it, it happens after a couple of minutes, if at all. I wonder if there’s some other application running on your system that may be interfering with the event loop or window redrawing. Do you have any applications that do things like draw into application windows or do screen capture?
Paul and Mark,
you are aware that you are hijacking this thread, right? 
Heh, sorry Ulf!
My apologies, too, Ulf!
No, Paul; nothing at all like that on my system, which is very clean.
If you’re working on this, maybe PM or email me so that we can exchange offline?
Thanks!
Hi Mark (and apologies to Ulf for prolonging this discussion). I’m not specifically working on that at the moment - the best bet is to add any more investigations or discussions to the other thread specifically about it.
Got it. Thanks. Definitely - sorry again… 