If you can wait a little then maybe get something like the CalDigit Element Hub or OWC Thunderbolt 4 Hub Docking Station (both around 150). Otherwise any other thunderbolt dock will be fine.
If you’re lucky you might also find a used OWC Thunderbolt 3 dock with Firewire.
I would also consider buying a Firewire800 to 400 cable to have one adapter less.

Hi all,

Since the last updates in big Sur , especially 11.2 my FF400 is not detected anymore at startup (red host light ON) and no way to play sound through the FF. This is resolved after I plug and unplug the FF to my iMac mini M1 (I use a firewire cable 400 to 800-> tb2->tb3 all mac adaptors which worked fine before). It's annoying to have to do this each startup so I was wondering if I could do something to fix this.

The other bug I noticed that is worse is that I now have trouble sending midi OUT through the FF400 to my synths. I've discovered that I have to go to Audio-MIDI devices in my system preferences in order to refresh the window for it to start sending out MIDI.

I regret doing this update since everything was going perfect . Thought there might be some CPU and VST related benefits that might be worth it but I guess it was the bad call.

I'm posting this here but if I should do another thread please let me know.

Thank you for the continuous support of your legacy products, you're the best.

Download the netifc again, but from the website. This is a newer version uploaded yesterday.

Sorry for bumping this – any clues at hand? Thank you!

Unfortunately the upload did not work, so you downloaded the old file again. There is an even newer netifc now, that includes some changes that might make it work in parallel to ZeroTier. Please try (see readme4.txt for details).

The manual for the Babyface Pro FS says: "Please make sure the Babyface Pro can have the full voltage/current delivered from the computer by using hi-quality USB cables (like the one included), no USB extension cables and no USB hubs."

So I would try it without using a USB hub, but just a simple USB-A to USB-C adapter. (Or get a USB-B to USB-C cable if you want to use just a single cable and not use the included USB-B to USB-A cable.)

Same here with my Mac Mini. Have to unplug and replug after Startup to get the FF400 working.

The new driver does make feth10001 available now.  However, it appears you are using a hardcoded MAC address for the virtual Ethernet port.  I have two Digiface Dantes, one on my PC rig and one on my Mac rig.  Both are using the same MAC address, which causes network conflicts.  So I can only run Dante Controller from one of the two systems.  Running it on both simultaneously leads to hiccups...  Please fix this (for both PC and Mac)!  Make it pick a MAC address on first run and then store that somewhere.

And the other unfortunate part about you having to use feth now is that Dante does not recognize it as a valid Ethernet port on Mac.  So Rednet Control doesn't allow it to be selected, even though Rednet Control is just control and not audio.  (I have no interest or need with the Digiface to run audio from DVS/DVia over the virtual Ethernet port since the Digiface provides proper Dante audio channels.)  Not sure if this is something you can work with Audinate on to get them to relax their interface filter rules on Big Sur...

Yes, the version I had previously downloaded was mac4.txt.  I downloaded the new one and looked at the release notes.  It's great you've already addressed the duplicate MAC address issue.  But in the end, I have uninstalled your net driver and purchased a cheap USB Ethernet adapter that I have connected to the second Primary Dante port on the Digiface with a one foot Ethernet cable.  The inability to use RedNet Control with feth interfaces is, unfortunately, a deal breaker for me.  The USB dongle gives me a standard "en" interface which is seen by the Dante APIs as a fully supported interface.  And I have spare ports on my existing USB hub, so it doesn't cost me a port on the iMac Pro.  (FWIW, the Digiface is connected directly to the iMac Pro, not via a USB hub.  It's one of the few devices with that privilege on my system...)

The issue is feth interfaces only work if you uncheck the 'shared' option in the Dante Controller network interface selector.  This allows it to work for Dante Controller.  But RedNet Control doesn't give you that "non-shared" option; it only works in Dante's "shared" interface mode.  And that means everything that isn't an "en" interface gets filtered out and is unavailable, because Dante doesn't think it is a "real" Ethernet interface.  (Dante also filters vlan interfaces out, which would be another way I could bring it into the Mac.)

Sorry, I haven't tried it since I already abandoned using the Digiface Ethernet on the Mac and am using a separate USB Ethernet dongle, as stated above.  And since I am not using it on the Mac, the Digiface Dante on the PC no longer sees conflicts.  While I expect the firmware is a relatively minor change, the PC is my main production rig so I can't really go testing stuff on it.  I can only do that on the Mac, which is the secondary machine (though still important).  I hope you understand.

Did anyone try the HDSPe driver with a PCIe card in a TB expansion chassis yet?

I should be able to test that in a week or two (OWC AKiTiO node duo), but was curious if there was anything I should look out for.

Thanks!

Oh thanks-

But that's with an intel MBA right?  I was curious if it works, or is expected to work with the M1 machines.

Finally had a bit of downtime to update the Digiface Dante on the main Windows PC to firmware 38.  And now Dante Controller does not work on the machine.  I see the Ethernet interface, I can ping the various devices on that interface.  But Dante Controller (v4.3.3.15) starts up and while it knows there are 5 Dante devices out there, and shows their names (but names only!) on the "Network Status" tab, all other tabs are blank.  RedNet Control also no longer sees any of the Dante devices.

Update was:
* Run update tool (downloaded today from the main RME downloads page)
* Unplug Digiface from computer
* Unplug power adapter from Digiface
* Wait ~10 seconds
* Replug power adapter to Digiface
* Replug USB to the computer
<at this point, all kinds of broken.  Can't ping anything on the Dante network despite Digiface ethernet interface showing back up>
* Reboot computer
* Verify Digiface Ethernet shows up and has correct IP address and can ping all devices on the Dante network
* Run Dante Controller, which fails to find anything as described above.
* Run Dante Controller on the Mac, and it is able to see and manage the entire Dante network.  The Digiface on the Windows PC has successfully auto-resubscribed all its Dante subscriptions.
* Verify that audio in and out of the Digiface is working correctly (it is)

I have the workaround of using the Mac to run Dante Controller to manage things.  But it's REALLY inconvenient that Dante Controller is now broken on the Windows PC.

https://forum.rme-audio.de/viewtopic.php?id=10662

Apple menu > System Preferences > Security & Privacy > Privacy tab > Microphone
Any audio apps need to have the Microphone rights enabled here.

Found the option in Cubase 11 and removed the check mark in Control panel! Thanks!

I too am having this problem. I updated to the latest firmware on my Digiface Dante and can no longer remotely control my Rednet preamps because of Rednet Control’s shortcomings. I am running a MacBook Pro with OSX Catalina. The system worked perfectly before. How do I downgrade firmware on the Digiface Dante?

Neil

I ordered the M1 Macbook Pro in November, and have been using it without any problems with the Fireface 802.

But now, after upgrading to macOS 11.3 I get a short audio dropout every 15/30 minutes or so. I'm using all the same hardware (via Apple recommended Satechi multiport hub) and pretty much the same software.


I just uninstalled the Blackhole virtual audio interface, that didn't help.


I (re-)installed the latest driver: "macOS 11 USB Series Driver 2021-04-24, driver_usb_mac_325.zip, USB 2/3 driver for macOS 11 and up. Version 3.25. Supports Intel and M1." That didn't help either.



I also tested using the internal 'sound card', and then indeed the drop outs are gone.


Any ideas?

So I think the issue here is the Audinate config file.  It stores both the name and the MAC address of the Ethernet interfaces selected (on Mac, you can use "plutil -p /Library/Preferences/com.audinate.dante.conmon.plist" to check its contents).  But with the Digiface Dante 38 firmware, the MAC has changed while the interface names stay the same.  On my Windows machine, I got it working again by selecting a different, totally unrelated interface and then setting it back to the RME interface.  This made it update the MAC address to match the new one.  I assume the same will work on MacOS.

I have the same problems as some others where I can't allow the USB driver for my Babyface in the Security settings regardless of what I do. The method of booting into recovery mode is not an option unfortunately, since I am on a remotely managed device. Is there any other workaround, or is this going to be addressed in a future update?

I am having a Fireface UFX (USB 2.0) which i run into a OWC TB Dock connected to my M1. The description of your glitches sounds very similar to the glitches i experience in Logic with this setup. Every now and then the glitches occur, and recording stops and restarts regular playback, or playback just restarts when the glitches occur. When i hook up a usb-c soundcard i own to the OWC it works just fine.

What seems now to be a temporary solution is using a USB B to USB C cable connected directly to one of the ports on the Macbook (I have to test this more) This also suggest to me that its not an issue with RME or the Mac, but probably related to the Dock. I need to do some more testing though to be sure. Bandwith issue?

PS i also tested connecting RME to one of the TB ports on the OWC with USB B to USB C. The issue stilled occur. Whats interesting is that you are using a satechi (unpowered?) an me a powered dock and our issues are similar. It might be a coincidence, but still interesting if you find a solution.

Hello all,

I just updated a 2016 MacBook Pro from Catalina to 11.3.1 and saw exactly what ABS and sramsay describe with my Babyface.

To recap:
- 3.25 driver install appeared to work normally, USB settings & Totalmix popped up (the babyface was plugged in).
- After the required restart, Totalmix won't load, USB settings show the babyface but it's set to 32k sample rate (weird), and no babyface in the system sound panel or in any apps.
- tried the recovery mode kext-consent bit, no luck there either.
- if I reinstall the driver, and before hitting restart, plug the babyface in, Totalmix pops up and we're good.  Until the restart.

Found a trick though - manually loading the kext with kmutil after the restart seems to straighten it out:

sudo kmutil load -p /Library/StagedExtensions/Library/Extensions/RMEFirefaceUSB.kext

Then plug in the babyface, and we're cooking.

and FWIW, it -does- require the sudo.  Without it, I get the following:

Error Domain=KMErrorDomain Code=71 "Insufficient permissions for action: Unable to load 'com.softraid.driver.SoftRAID' in unprivileged request." UserInfo={NSLocalizedDescription=Insufficient permissions for action: Unable to load 'com.softraid.driver.SoftRAID' in unprivileged request.}

Variations on this occur! It seems as if it's trying to load everything in StagedExtensions, which for me included this SoftRAID thing and some VirtualBox kexts.  One of them will barf each time ...

So it seems it's not an issue with the RME driver but rather with loading old kexts, and maybe the permissions around that have changed with the OS update.

Gonna stop there because it's pretty much the limit of my understanding, but maybe this helps.

Nick

Thanks for sharing. Yep that sounds very similar. I will probably test the USB-B USB-C workaround soon.

I can't really pinpoint which software causes it. But I did notice some odd CPU spikes in Ableton that seem to correlate with the drop outs (and sometimes glitchy drop outs). It's just weird that this happened since upgrading from macOS 11.2 to 11.3.

I think the glitches occur when I power the macBook via the USB-C multihub as well as when I power the MacBook directly and leave the hub unpowered.