Hi MC,

Changing the main fader level on the Babyface doesn't any difference. The Main fader in TotalMix is assigned to AN 1/2, hence is controlled by both the Babyface rotary dial and macOS system volume (they all change in unison), and the Babyface Pro AN 1/2 outputs are connected directly to my amplifier XLR inputs.

My monitors/amplifier do not have any level controls. These are Amphion amp/monitors so we're not talking about some cheap monitoring system. The Amp100 has precisely one control: an on/off switch. The One15 speakers have precisely zero controls. Presumably Amphion expect the level to be controlled by a monitor controller. But the Babyface Pro is my monitor controller. I thought that's why it sits on your desktop and has a rotary dial, no?

As for audio listening levels, it seems fine - the relationship between Babyface level control and audio listening volume seems absolutely fine. But the volume of the "Thwip!" power-down noise is completely fixed, and there is no level I can change which has any affect on its volume - except to switch OFF the amplifier, so that is what I do.

To be clear, this isn't your typical on/off electrical impulse sound. It doesn't make the "woofers bump". It's an extremely high-pitched noise that rapidly sweeps through the frequency spectrum from high to low, and sounds like it's mainly coming from the tweeters. Have you tried reproducing the issue by disconnecting from a Mac USB-C port? Perhaps, we are not be talking about the same thing.

This report sounds exactly like my Issue 3 - they are saying, if the RME device is already powered up when the MBP boots up, then it is not recognized as an audio device. But if they disconnect/reconnect, it is recognized. The only difference is they have a Fireface UC which is presumably mains powered and has an on/off switch.

However it does not describe my Issue 2 - that is, after disconnecting/reconnecting the BfP on a running MBP, it's (intermittently) not recognized by macOS on reconnect, requiring a reboot - and furthermore, once in this state, the MBP always hangs during the shutdown process (black screen with a frozen pointer), forcing me to do a hard reboot by holding the power button.

I accept the issue is on Apple's side, and the underlying cause could be the same or closely related. But I don't think you can say definitively it is the same issue - not without a root cause analysis.

Details matter with these kind of things - an issue that requires you to reboot your computer is much more serious than one that requires you to disconnect/reconnect your audio interface. And an issue that makes your computer hang during the shutdown process is much more serious than one that requires you to reboot your computer.

These are different symptoms - and they may have the same or related underlying cause.

He's talking about how it works with some cables, and not others. Surely that can't be a software issue?

Has RME made any attempts to inform Apple about this? Or is that considered to be a waste of time? Apple can't fix what they don't know about.

OK, i'm currently listening at around -40 dBFS, sometimes even lower.

Do I need to get a passive voltage divider/attenuator, or can I continue working round the issue monitoring at low level and simply switching off my amp before I power down the BfP? Normal audio sounds fine as it is.

I guess there's a danger that if for whatever reason the macOS system volume goes to 0 dBFS then it would be, let's say, painful...

Where can I get a passive voltage divider/attenuator that has no effect on the audio quality?

OK thanks.

There is no problem in constantly re-charging the laptop, Apple has taken care of that. A power supply for the BF Pro can be got in many places, 12V/2A is nothing special, maybe you even have one lying around so you could try it. Indeed current consumption from USB is zero when an external power supply is connected to the BF Pro.

I should add that Issue 2 is a bit of a pain, because there are several real-life scenarios where the Babyface Pro needs to be disconnected from a MacBook Pro:

1. When taking the MacBook Pro away from my desk. Since it's not safe to disconnect the Babyface Pro from a running Mac using USB-C, I have to first shut down the Mac before disconnecting.

2. When switching off mains charging via a USB-C / USB 3.0 hub that is providing both "power delivery" to the Mac and audio for the Babyface Pro. I can also reproduce the issue using Apple's own USB-C to USB adaptor - but due to lack of ports, I normally share the Babyface Pro with a power delivery hub.

I asked Plugable why USB devices drop when a USB-C / USB 3.0 hub is switched from charging to not charging - and they said this is inherent in the current revision of USB-C, adding "this should be fixed in later revisions of USB-C and associated products".

For this reason, using an external power supply with the Babyface Pro doesn't really help. If I put the MacBook Pro to sleep and switch off charging at the mains, the USB hub momentarily drops the Babyface Pro, regardless whether the Babyface Pro has its own power supply or not. So now I just leave mains charging switched on while the mac is asleep, and let the Mac take care of battery management. I only switch off the charging USB hub when the Mac is fully shut down.

3. Finally, USB-C plugs seem physically quite loose and can disconnect easily.

All the above can trigger Issue 2.

Another quick update on this topic. From my original post, ISSUE 2 is the only one outstanding; the other two issues are resolved.

RME have made it clear that this issue is on Apple's side. So I've been waiting and hoping that Apple will eventually fix this issue.

Well, today Apple released macOS 10.13.2 - and the release notes say "Improves compatibility with certain third-party USB audio devices". So, I tried installing the update and testing this issue to see if it's fixed. 

Unfortunately it is not resolved.

The behaviour is exactly as before. I can reproduce the issue 100% reliably as follows:

• Disconnect all USB devices from the MacBook Pro

• Connect only the Babyface Pro using Apple's own USB-C to USB-A adaptor

• Play some audio e.g. in iTunes

• Disconnect the Babyface Pro while the audio is playing

• Reconnect the Babyface Pro

Expected behaviour: the Babyface Pro re-appears as a working audio device in System Preferences > Sound > Output.

Actual behaviour: macOS fails to recognize the Babyface Pro (no audio device in System Preferences > Sound, and Fireface USB Settings app does not start). The issue can only be resolved by rebooting - HOWEVER when I reboot the MBP in this state, the MBP ALWAYS hangs during the shutdown process (black screen with a frozen pointer). This forces me to do a hard reboot by holding the power button.

The same issue also happens (albeit less reliably) if the device is disconnected/reconnected when audio is not playing - that means the issue can occur quite easily during normal usage, for example when taking my laptop away from my desk to go travelling.

So it's back to waiting I guess...

I was reading this post and just had to add - as I think its crazy that anyone would power of a sound device without an attenuator/fader or turning of their speakers first.  For example in a  pro studio you wouldn't power down a desk BEFORE turniong the speaker of as you are likely to blow them.  This is no different - even if the Babyface pro had a power of switch you would still have to power the speakers of first.

a couple of weeks ago, I picked up a Babyface Pro to use with my 2016 Macbook Pro, and immediately experienced the Issue 2 as reported above. I'm a long time Metric Halo user, and they had a similar issue with a bug in OS X, and suggested a workaround that I'd been using problem-free for a few years until recently (when they wrote a workaround into their driver code). after experiencing Issue 2 on the Babyface, I re-applied this workaround. I've been in heavy sessions with the Babyface Pro all week long in a variety of settings and have not experienced Issue 2 again. I cannot guarantee the problem is gone, but I've probably plugged/unplugged the interface 20-30 times over the course of the past week since applying the workaround and the problem has never shown itself again. (knocking on wood) below, i'll reprint the exact workaround from Metric Halo. BJ from MH has always insisted that this fix will not harm your computer and you can easily revert back if you don't feel comfortable.

best of luck,
jake rodriguez
***************************
Hi Folks,

I know we have posted about this here before, but I think until the problem happens on your system, the issue does not register, and when it does, you may not make the connection to the post that was made months ago.

The issue with playback not starting (usually followed by various apps hanging) is a result of a bug in OS X that affects OS 10.8 and higher; it has been acknowledged by Apple, and they have decided not to fix it.  Unfortunately, it is not something we can work around in the driver, but there is a work-around that you can apply to your system that will prevent the bug from occuring.

You can do the following to work around the problem:

If you are on a Mac running 10.10 or higher, please follow these steps.

reboot and hold cmd+R until the progress bar appears

when you are in recovery mode (macOS Utilities window), choose Terminal from the Utilites Menu

in the terminal, enter the following exactly (followed by the return key):

                 nvram boot-args='dart=0'

Select Restart from the Apple Menu

After that the problem should no longer occur.

To verify that the fix has been applied, after the machine has rebooted, you can open the Terminal command and run the following command (again, copy/paste):

nvram -p | grep boot-args

This should show the output:

boot-args    dart=0

if the fix was applied correctly.

If you reset your PRAM, or update your OS, you will have to run the first command again, as those two things clear the NVRAM that store the boot argument.

Best regards,

B.J. Buchalter
Metric Halo
http://www.mhlabs.com

First, this issue occurs when disconnecting USB devices even while no audio is coming out. I only mentioned disconnecting while audio is coming out because it's is easier to reproduce the issue that way - and it's always encouraged to provide vendors with steps that allow them to reliably reproduce an issue.

If you're saying devices should not be disconnected even when NO audio is coming out - well, that would mean that if you're using a laptop with a bus-powered audio device, you need to fully shut down the laptop every time you take it away from your desk.

But before you do that, you need to remember to power down your speakers. Because according to you it's not safe to disconnect your audio device until your laptop is shutdown, and according to the previous poster it's not safe to shutdown your laptop until your speakers are powered down.

So you have to always remember to do things in exactly the right order: 1) power down speakers 2) shutdown laptop, 3) disconnect audio device, and 4) remove laptop.

This is all fine. But at the end of the day this is not how these things are designed to work. It just isn't. Laptops are designed to be portable. Bus-powered audio devices are designed to be plug-and-play. Operating systems are designed NOT to hang!

If an operating system hangs when you disconnect your bus-powered audio device, something is wrong. It is perfectly reasonable to identify this as an issue (and in this case it happens to be an Apple issue).

understood. i will post another of BJ's early posts (sometime around 2014) when he described in more detail. i have used this fix on my laptops since around that time without any known issues, but i get wanting to be wary. hope this is helpful in your decision. fwiw, i have still not experienced the Issue#2 since applying this fix, and have hot-plugged and unplugged dozens of times.

cheers,
jake
*************************
from MIO-list circa 2014:

Hi Gary,

This is actually a bug in Mac OS X and has been reported to Apple and acknowledged, but not fixed (it appeared in Mac OS 10.8.2).

The Apple bug number is rdar://13093900

I have discussed this further with Apple engineering and while there is no way for Metric Halo to fix this or patch around it, as it is a bug in Mac OS X, there is a user-level work-around that you can apply that will fix the problem for you while we wait for Apple to fix the root-cause.

The problem is occurring because of a change Apple made to the IO layer in Mac OS X to protect against physical access attacks via Firewire and PCIe (Thunderbolt). This is called VT-d (it is an intel technology built into the Processors and Chip Sets) and it virtualizes hardware access; in particular, it denys Memory Mapped peripherals access to all of the HW memory map except for buffers that have had specific access rights granted by the OS. Apple's FireWire driver is supposed to grant access to the FireWire hardware (Apple's -- not MH's) via their VT-d driver. The bug you are running into appears to be a hang or infinite loop in the VT-d driver while trying to allocate the access window.

So, the work around it to turn off VT-d. This obviates the security that VT-d provides, but no Mac had VT-d before 10.8.2, and your problem is related to a bug in Apple's VT-d driver, so you are not really losing anything you ever had.

Best regards,

B.J. Buchalter
Metric Halo

This 'workaround' fixes the USB2 and Touchbar crash on our MacBook Pro 15" that happens when disconnecting a USB 2 interface while audio is running.

We had send a bug report to Apple that also found VT-d involved (several months ago), but were not aware of any method to switch it off. Cudos to Mr. Buchalter and sounjaerk for publishing this useful info!

I have tried this workaround but it did NOT solve the problem.

My setup: MBP 2016 with High Sierra + Fireface UFX or Digiface USB

Latest drivers installed.

This needs more attention and testing across different hardware configurations from you guys @ RME. I understand it's coming from hardware changes at Apple, but the problem is NOT fixed and should not be treated as such.

Hey,
today I tried again to find again workarounds for these problems I have with my Fireface uc and my MacBook Pro 15 inch 2016.

My biggest issue still is the need of a hard reset (or even sometimes then reinstalling the OS) after I hot deplugged the interface or I switched off the interface while used (for example in Logic or MainStage).

I tried the Workaround by sounjeark and like for plsmk I didn't work. I still have the same Problem. Is there anything I can do?

Best Regards from Germany

Michael

Hello, found this thread helpful. Is the bug resolved yet?

I have a MacBook Pro 2017 on high sierra  USB-c only.  Will the Babyface pro function with apple’s USB-b adapter?

Won't work, as you need a USB connection from the computer to the recording interface so that it can be accessed by its USB drivers. Besides that, the recording interface would have no drivers to handle USB based Wi-Fi devices.