Never seen before.
Bitwig and Totalmix are fighting each other for the Microphone lady ?
MacOS can't handle this.

i did a test and both apps are working with no issue.
Ventura 13.4 update today
RME driver 408 with the Digiface USB
BitwigStudio 4.4

No such luck unfortunately.  Is there an official RME support channel for this kind of thing? I very much doubt that this is Bitwig related, it looks like this is between the driver and the OS.

It's hard to say because I pretty much always use Bitwig and my RME devices at the same time. 

I can try and a) use my UCXII for non music-related things and see how it goes b) shut down Bitwig next time it's happening and see if it stops.

It's a little strange because sometimes I can get it to stop by opening Totalmix and recalling a different snapshot or jiggling something (but not always so not very conclusive). 

Any suggestions on getting more information?

In the Mac system preferences : security & privacy - Microphone
Check if Totalmix and Bitwig are enabled for access.

So I talked to Bitwig support, and their thinking is that because it doesn't happen with internal audio on the MacBook it is not happening inside the Bitwig audio engine and is somewhere between coreaudio and the RME driver.

Can somebody from RME comment on how I might go about getting more information? I'm happy to do anything I can to help track this down.

If anybody else feels like having a go at testing this, I've noticed that it's a lot easier to reproduce at high buffer sizes - I've been running at 2048.

I'll do that if I get some time.  However, at this point I'm pretty comfortable saying it's an RME driver issue because:

- Have spent hundreds of hours using the internal audio (when I'm not near one of my RME devices) in the same situation without issue, whereas I've spent about 1 hour trying to reproduce unsuccessfully with Reaper.
- It's noticeably worse with the 4.08 driver than with the 3.28 driver.

I've emailed support officially (which might be you anyway?) - I'd forgotten there even was a support email for RME

Are BF Pro and UCX II both used? Above you mention BF Pro, but in the video TM FX is not connected to the BF Pro. To further find the cause you should use only one interface and restart TM FX so that in the device list only the current one is shown.

Then for a further test disable the mic inputs of the interface and only use the other channels in a project.

b
Depending on the DAW active input channels can use CPU and causing dropouts.

No change - no inputs registered in Bitwig, same problem.

https://drive.google.com/file/d/19k2hrL … jlElv/view

Isn't that Scarlett a Class-Compliant interface ?
If so, then how does it compare to the Babyface CC ?
Press and hold the two buttons SELECT and DIM during power up switches between CC-mode and Computer-mode.

Next test should be with a different DAW.
Reaper is perfect for testing. For free.

You may have to rollback to the previous driver :
https://rme-audio.de/downloads/driver_usb_mac_328b2.zip

Hi
On the way to sort things out, I discovered there is one reason to show Totalmix as an app using the "microphone" in the control menu (top right): it's only when reverb and/or echo effect(s) are enabled. The Babyface pro is the only interface which cannot process the effects on the internal DSP. It sends the audio to the computer over the additional channels 13/14 to process it on the host computer's CPU. On my Mac (M1 mini, Ventura), TotalMix appears only in that specific moment in the control section, as soon the effects are disabled, it's not there anymore. Can you check this once? Do you have effects in use?

The plot thickens:

https://drive.google.com/file/d/1D3xYgD … drive_link

I installed Jack to see what I could learn, and despite Jack using CoreAudio under the hood, the problem does not seem to be present when using Jack!

I think this pretty conclusively isolates the problem to CoreAudio somewhere in the layer that handles the output from the DAW, does this make sense?

DAW => CoreAudio playback API => CoreAudio routing => RME driver => RME device (problem exists)
DAW => Jack playback API => CoreAudio routing => RME driver => RME device (no problem)

Now the puzzling scenario is:

DAW => CoreAudio playback API => CoreAudio routing => CC driver => Scarlett device (no problem)
DAW => CoreAudio playback API => CoreAudio routing => CC driver => RME device (problem exists)

I'm going to revisit that last one and make sure I didn't make a mistake in testing it.

I use the UCX II and the Babyface independently, they are in different locations, so they're never connected at the same time.  I'm working with the UCX II at the moment since I'm at home, but I'll try that the next time I'm in the studio.

Attempted to do a reinstall of Sonoma, no help.

Bizarrely, it seems like I have fewer dropouts when I crank the buffer size down to 256 or so than when I use 2048.  Looking at CPU usage, it seems like some of the load is shifted away from the performance cores when the buffer size is large.

Ok.  Fingers crossed, I think this might actually be fixed.  It looks like that might have been the key:

BIG FLASHING LIGHTS
The Apple silicon architecture does not respond in the expected way to jacking up the buffer size, which is what I've always done to fix problems like this.
/BIG FLASHING LIGHTS

It seems like once you hit a high enough buffer size, the M1 moves work from the performance to the efficiency cores.  Once that happens, the work scheduling can no longer fill the buffer in all situations, and it's dependent on whatever magic algorithm Apple is using to decide which cores to use, which is why it's been so difficult to track down.  This must have interacted with the userspace drivers in a different way than previously, so it got worse with the 4.0.82 driver.

Using 256 sample size and saw no issues this morning as opposed to my previous 2048.

Hi MC,

I'm not sure which of these questions you're asking but:

1) Am I currently on Sonoma beta?
Yes, Version 14.0 Beta (23A5328b) with 4.0.82 drivers.

2) Does the comment above (#36) about the buffer sizes and the performance vs efficiency cores refer to Sonoma beta in particular?
No, I believe this has always been the case.  Ableton has an article about it (https://help.ableton.com/hc/en-us/artic … ilicon-Mac) too bad I didn't find it sooner. 

It seems Apple did improve something related to memory pressure in the Sonoma beta, there are lots of people in this thread (https://www.audiosciencereview.com/foru … pro.42001/) who are reporting their issues fixed by the beta, but the beta alone was not enough to fix my issue so I believe the primary problem was having my buffer size set too high.  It seems plausible the buffer size change alone would have fixed my problem pre-Sonoma.

You can see here where I increased the buffer size: https://drive.google.com/file/d/1UHOCeY … drive_link