Sound issue in MimoLive

I already submitted to tech support, but maybe a user can shed additional light on this? I am running a Macbook Pro 13" w/Touchbar. 2018 version. I’m running MacOS 14.14.4.

While we were broadcasting, the audio started to buzz, like it was being pixelated, voices and sound were distorted as if the sample rate went waaay down. The audio coming out of the program mix, however, appears clean. It was only my local monitoring mix (Audio Mix 4) that was buzzing. Turning the mix off then back on seemed to temporarily correct the problem. It would last for 5-10 minutes, then start degrading again. The Interface is an Apogee Element 24. The interface is a Thunderbolt 2, connected to the Macbook with an Apple Thunderbolt 2 to Thunderbolt 3 adapter. The interface works fine in other audio apps so it is not a hardware issue. My internet is gigabit, coming over a direct Ethernet connection. Usually I turn Wifi off when I broadcast. I’ve tried the current version, and the last version 4 release–same issue.

Anyone have any thoughts as to what might be going on?

I had the same issue yesterday. Sound on livestream was ok, sound on audio monitoring on my headphone connected to the MacBookPro 15" made this strange noice after a few minutes. Off/on on the monitoring solved it for a few minutes.

Any insight into this? It is still happening.

Unfortunately, we’re still looking for the key hint. I have this sometimes on my machine and after a restart of mimoLive, it’s gone. This makes it hard to track down. Thanks for your patience.

I have some test video that demonstrates what appears to be a similar problem. I will send a link when I have time to annotate and explain.

I found the output problem while trying to nail down the details of the input problem I’ve mentioned previously. My temporary solution to that input problem requires inserting Loopback (audio routing software from Rogue Ameoba) into the chain between the input audio device (MOTU Ultralite AVB, running audio over USB) and mimoLive. When mimoLive uses the Loopback ‘device’ as its input, it doesn’t have the same issues. The primary symptom of this input problem is that the audio gets out of sync with the video.

Back to the output problem though … The signal waveform looks a bit like there are two signal paths getting mixed together somewhere, with one of them slowly going out of phase …

Anyway, I’ll find the test video and put it somewhere when I get time. I can definitely reproduce the problem. The routing I’ve used to capture the test is a bit tricky to explain though.

OK. I found time to get the video online while I was thinking about it this morning!

You can find the test demo video here:

So here’s how the routing went. I fed the output of the “Test Video & Audio” source into an audio mix (‘Initial Send to Ultralite’) which was sent out (over USB) to my MOTU Ultralite AVB audio interface. This was monitored via headphones, but also routed back internally in the MOTU DSP mixer/router to an input channel which was brought back into a mimoLive mix (‘Returned Audio from Ultralite’) and recorded into the screen capture video you see.
I monitored the audio output with headphones to make sure that the audio was getting messed-up on output and not on input.
I mentioned an audio input problem above … this was the original reason I made the recording. You can see this also if you look closely at the exact timing of the audio signal which is returned … but let’s deal with one at a time …
The audio gets pretty bad from around 3:20 in that video. You can hear a weird effect and if you look at the waveforms you can notice some strange shapes …

Thanks for taking the time to investigate. This is very helpful. Engineering will take a look asap.

Oliver, I think I’ve isolated an example of the audio timing drift on a USB input that I mentioned above. What’s the best way to get the large files to you? … they don’t show much, but they’ve certainly helped me isolate that I’m not completely crazy … :slight_smile:

Can you please send the large files via Dropbox or WeTransfer?

Yep, that’s it. Hope it can be identified and fixed soon.

1 Like

Any progress on the USB drift issue? I heard a rumor that somehow the Mac’s T2 chip on the newer Macbooks has something to do with it. I’d love this to get resolved!


Oh, and btw, my interface is Thunderbolt. You guys really need to get this fixed. It’s been 6 months.

I’ve been having this issue since i got my macbook pro. thing is it has to be the mackbook pros because i run the same mimolive on two other Imacs and did a side by side 30 minutes test. the results were the same every time. the macbook pro “Audio Monitor” would start buzzing out after a few minutes while the Imacs ran forever without that issue. I never made a complaint because i thought my Macbook pro’s Sound card was faulty. Another thing that i tried was instead of internal Macbook pro speakers i plugged a headphone in, turns out the same thing happens to the headphones as well after about 10-15 minutes. however all it takes to fix the problem in my case is to disable Audio monitor & Activate it again then it works fine for 10-15 minutes… so not a big issue for me. Fixing will be great though.

Yes, I’ve heard that as well. There seem to be numerous issues with audio and the T2. However, we’ve not been able to reproduce it and link it to the T2 chip yet. The investigation is ongoing.

This bug is haunting us because we can’t reproduce it so that we can test for fixes. But it is on the top of our list. Thanks for your patience.

So I ran Mimolive while watching the Console for audio errors. Several things popped up:

default 20:45:36.994842-0600 coreaudiod HALS_UCPlugIn::ObjectGetPropertyData: [‘srnd’, ‘outp’, 0] failed: 1852797029

I got this error 4 times.

I also found something curious. Whenever the signal started to degrade, this would show up in my console:

22:47:07.346082-0600 mimoLive 820403818844375 MOV-VarispeedRenderProc:655 filling audio buffer with silence because no input was available (yet).
22:47:08.378448-0600 mimoLive This error occured 5 times within the last 1.032379 seconds: 820403845433421 MOV-VarispeedRenderProc:655 filling audio buffer with silence because no input was available (yet).

Then an even curiouser thing happened. While the audio was playing in Mimolive, I switched the playback of the Host minus mix from Element 24 (my Audio Interface/Headphones) to my Thunderbolt dock. That seemed to have reset something because the sound played just fine from my speakers. I tired this again–wait for signal to degrade in Mimo, switch to Macbook pro speakers and again, the audio righted itself. I’ve copied my entire console log (filtering the word “audio”). If you like I can send it to you. Just tell me what email address to send it to.

What I’ve noticed too, is that the audio gets so bad it just stops. Again, turning the mix off, then on fixes it for a time.

Is that at all helpful? I’ve not noticed this behavior in any other app.

1 Like

Another thing I tried: I opened up Apple Music and played the radio through the Interface (Element 24) No issues, audio sounded fine. While the audio was still running, I started up my theme song in Mimo. Audi sounded like a mess. This is definitely a Mimo issue.

I wonder if there was a way to reset the audio connection every minute to so, to flush it out? Would that fix the problem?

1 Like

Oliver, I think I’ve disconnected a case of the sound planning float on a USB input that I referenced previously. What’s the most ideal approach to get the enormous documents to you? … they don’t show a lot, however they’ve absolutely helped me separate that I’m not totally insane

Can you make the document available to us via WeTransfer?

Hi there,
had a few shows with my AirPods as Sound controll device, no problems.
Yesterday, I forgot them and used the ‘normal’ headphones from an Apple iPhone again, and the error turns up again.

Been having this issue for ages too. I use Robe USB mics and have to turn on/off the audio input to get it back in sync. Gradually the sync becomes worse and have to reset every 10 mins or so. Annoying.