Did it come with a manual? Just asking.

If so, pages 9 to 10 may be helpful, as they lay out the manual operation of the unit.

That worked. Really should have been simpler and more intuitive to set up, but I guess that's what I signed up for when I switched to Linux. It really sucks to frequently only get a fraction of functionality you pay for, but that's the price of freedom these days.

But just imagine being the first company to release a device with full Linux support and basically capture close to 100% of that market for a couple of years, until others figure out that there is money to be made there.

Thank you for your help. I guess I'll go register the product and the extra software and hopes that some day I'll be able to use that too.

All 12 input channels are always available in CC mode.

> At $900.00 one would expect this to work out of the box

Sure for Windows and Apple. These two operating systems are officially supported by RME.

Some RME devices, like BBF Pro FS, have a so called "Class Compliant mode" which is an OS independend standard.
CC mode works fine for Windows and Apple.

There are so many Linux Distributions out there (>200) ... some people claim, that class compliant mode works for Linux.
But which Distribution works best or for what kernel and sound daemon infrastructure I can't tell you, sorry.

Kind of "RME bashing" doesn't help you any further, RME made no promise or claims that it runs on Linux.
It's simply in your own responsibility to choose an Operating System which is not officially supported by RME.
Some people got it running on linux, maybe they can speak up, which distribution they choosed or
what "magic trick" on Linux made it work.

There is a Linux Subforum on RME Forum where you can ask and potentially get highest visibility for these kind of things.

Or alternatively ask in the Linux ALSA forums where you reach users and devs of the ALSA sound system.

There are also other sound systems available on Linux, but I remember that ALSA brought some support for some RME recording interfaces. They also maintain a database of which sound cards and recording interfaces are supported by them.

> There is nothing stating that RME interfaces don't work with Linux.

Its the other way around. You have a good chance to get it running on OS which support audio devices with CC mode.
If it does not work, then its your responsibility to get it running under Linux.
Either by contacting people who maintain your distribution of choice and to get the clue what the show stopper is or
by checking the other around 250 distributions on your own by trial and error.

I have two other audio interfaces that both work without issues. They are lower quality and older, thus latency is not great, but they both work "plug and play". Inputs are available and I get audio from them. That was not the case with the Babyface.

I either got a defective unit or there is a problem with your CC mode implementation.
I will eventually pick up another manufacturer's Audio Interface and let you know if that one worked. So far all interfaces I tried and have access to have worked except for the Babyfaace.

Hi,

@bollie, that would be awesome!
I'm also a long time linux user and having EQ on the babyface under linux would be really nice!

greets,
Michael

Awesome work! Please let me know if you need any help testing the changes. I'm happy to patch my kernel and give it you changes a shot with the babyface pro (non fs).

Hi very pleasant news here , will keep looking into,
thanks for your work Bollie !

Awesome work!
Any chance this, at some point in the future, might also work with RME Babyface (non-Pro)?

As far as I understand it, the kernel patch by Bollie is strictly conditional on the USB device ID of the Babyface Pro (2a39:3fb0), but the original Babyface has a different one (0424:3fb7), so it wouldn't work as-is.

Thanks @Bollie for your efforts and contribution! This is encouraging to switch even more to linux.
Great to hear, RME is a company that was supportive. It's not a given nowadays and deserves kudos.

@Bollie, first of all thanks on working on this.

Could you do me a favour and list what changes with your patch, but also which restrictions still remain compared to the official drivers? Because as far as I understand the the BF still runs in CC-mode.
The Phoronix News page just mentioned that the patch will "properly support" the device.  I imagine that mean "properly supports mixing features in CC mode" and not "properly like on Windows- or Mac-PCs.

I wonder about stuff like:

- latency
- sample rate quality
- loopback feature
- number of software outputs
- internal routing matrix of the BF

The reason why i ask and the position I am in is as follow: I do not own the BF yet. I would buy it despite the fact that it's far above my average budget, IF i knew i can use it for many years on both WindowsOS (which I currently use mostly due to gaming) and Linux. Beside using it for simple audio output (music listening and gaming), I would like to use it in a DAW-software (like 'Reason' on Win10 or e.g. Bitwig in Linux) combined with a midi-keyboard as well as voice recording.
  Each single thing should work well enough on both OSes. However the tricky part comes when streaming things. I would want to mix the outputs of these softwares + the microphone input internally in TotalFX and route them to a single software input that is assigned to the streaming software.
  As far as I understand, this works in Windows due to the multiple software outputs of the driver, the internal routing matrix of TotalFX and the loopback function. But would that work in Linux as well?

Thanks for taking the time to answer my post.

The Unix diff contains the path name to the file, that needs to be patched.

For kernel patches you usually need to stay on the toplevel directory of the kernel source tree.
And of course you need to have
- the kernel sources and the
- development system
installed on your system, which is not always the case.

And even if you stay in the correct directory the path names in the patch can still differ a little bit based on the directory structure and file organization of the developer.

See the discussion here: https://unix.stackexchange.com/question … hould-i-do

Should you see in the patch file, that original and modified files follow this directory pattern:
  a/include/linux/pm_qos.h   <--- the original file
  b/include/linux/pm_qos.h   <--- the modified file
then you need to execute the patch command with -p1 so that the 1st subdirectory "a/" and "b/" will be omitted for finding and patching the files, e.g.: patch -p1 < kernel.diff

Its no rocket science, you are only not used to work / think like a Unix power admin / developer ;-)

After patching the kernel sources, you need to recompile and install the kernel.
There are surely internet Wiki Pages available how to install kernel source and how to compile and install a new linux kernel.

On FreeBSD this was easy, something like: root# cd /usr/src/sys && make all install clean

Don't forget to become root on your system (might need sudo command) to have the "power" (needed rights on your system).

Some general information for recompiling kernels: https://unix.stackexchange.com/question … all-change
This seems to be the Debian way: https://kernel-team.pages.debian.net/ke … n-building

As the Debian documentation distinguishes a little bit whether to compile a new kernel either from Debian kernel source or from "pristine" kernel sources, see those chapters,
    4.5. Building a custom kernel from Debian kernel source
    4.6. Building a custom kernel from the "pristine" kernel source
it seems to be important to look whats the best way for "your Linux distribution".

Another good way to gather information is to look into the README file to this ALSA patch whether the author of this diff recommends a procedure how to compile and install the change.
Maybe a full recompile is not required maybe only a recompile of a kernel module ... check it out.

Good luck.

I recommend asking on the ALSA mailing list or a forum, I am pretty sure that some other linux users also stumbled over that already.

Note that this is not 'Volume', but the Gain of the mic/line preamp.

@Bollie, I've packaged it for Nixos, and am almost ready to create the PR. It works on my machine(tm) so we know it's production-ready...

The commit is here in my fork of the repo; I'm happy to make any tweaks to the metadata you'd like, particularly in the description.

Now, here's the question every developer dreads: do you have a license in mind? The default for Nixos is "unfree", which means people need to take extra steps to enable it. Please feel free to PM me, if you'd rather take this discussion off the forum.

Also, thanks for creating this!

It has, as far as I can tell. My Babyface Pro FS just works(tm), and works very nicely.

bbfspromix also works, in case you're thinking of using that as well.

On 'field work' I would use an iPad

Hi everyone!

I just got my new Babyface Pro FS, using it in CC mode on Ubuntu 20.10. I use ALSA only, not Jack.

Everything I've tested so far is working fine out of the box (playback, recording via the two XLR inputs).

I've installed bbfpromix as well.

I am having two issues which maybe some of you may know about:

1) If I am recording input 1, I get monitoring only on the left side of the output. Same thing if I record input 2, then the monitoring is only on the right. This is OK when I record stereo sources, but when I record a mono source such as vocals, this is uncomfortable. Is there any way I can make the BBF treat Input 1 as a mono input and monitor it on both sides of the output?

2) In bbfpromix, and in alsamixer as well. it seems that the only control that have an effect are the 48V and Pad settings for inputs 1 and 2. Any other parameters (volumes, pannings) have no effect whatsoever. Has anyone else experienced this?

Thanks for your help!
Vincent

Wow, I didn't expect such quick help. I had actually falled in to the "trap" you were refering too. Now that I understand that, everything works fine, volumes, pannings and all! Thanks a lot for your help