Looks like the main difference are the fifty-gazillion instances of these two lines in the log of the first (problem-ridden) debug:
-0700 mimoLive Reconfiguring inputDeviceFramebufferSize:
-0700 mimoLive Setting buffer size to
I’ll bet you that’s where our bugs live. In fact, the dropouts I’m hearing sound just like what happens when I change the Audio Buffer Size manually in Preferences.
@camsna Thank you for keeping at this and reporting your findings. We appreciate your patience. Engineering is looking at your data.
@camsna @“Cameron Aanestad” @MrAndrewMcLean @“Janne Olsson” @Jordan
It currently looks like there are two separate issues that produce the behavior you describe:
1 - A bug introduced in mimoLive 4.3b3 that is being addressed in the next beta. It would be great if you could test it as soon as it gets available which should be this week, hopefully.
2 - An issue that has been plaguing mimoLive for a longer time and has to do with the way how mimoLive acquires audio data from Blackmagic Design’s DeckLink SDK and how macOS interacts with that process under certain circumstances. As an example I am able to produce the audio artifacts that some of you describe in this thread when switching between apps, when triggering UI changes in mimoLive, like e.g. opening the app menu, or when starting to load content over the internet. When or how often these actions cause audio artifacts is inconsistent, only their occurrences do match. In my tests triggering one of the described actions for the first time was much more likely to cause an audio artifact than triggering the same action afterwards.
BTW in regards to 2. we’re in contact with Blackmagic Design.