Hacker News Reader

Comment by drewg123 | Hacker News Reader

I wonder if this is the end of drivers for 3rd party PCIe/thunderbolt high performance NICs? I imagine that this may make Macs less viable for situations where having a reasonably high performance 3rd party NIC is important (eg, video editing).

Are there any details about DriverKit that are available?

I used to be a Mac driver developer ~10 years ago or so. I did one of the first 10G drivers for Macos, and MacOS performance was always terrible compared to Linux or BSD, but I can't imagine that moving it into userspace is going to help anything. MacOS boundary crossing (eg, syscall, ioctl, and Mach traps) performed even worse than their network stack as compared to Linux/BSD.

View on HN

Yes, WWDC video

https://developer.apple.com/videos/play/wwdc2019/702/

https://developer.apple.com/documentation/driverkit?language...

https://developer.apple.com/system-extensions/

Regarding performance, on the other hand Linux/BSD still don't match macOS real time audio capabilities.

At least its found one thing to be good at.

Sadly not. Many professional DAWs rely on custom kexts and are therefore advising their customers against upgrading.

> Regarding performance, on the other hand Linux/BSD still don't match macOS real time audio capabilities.

Got a source for that? I use a Debian machine for an audio workstation. I moved there from OSX and am using the same DAW and get less latency now. Especially because I can run a real-time kernel...

The source is what professional musicians get to use.

They don't have to customise their kernel on the newly bought Window/macOS laptop.

That doesn't line up with your original argument

You said MacOS got better performance in realtime audio

Just because it's what musicians "get to" use doesn't make it better. It makes it a standard

Sure it does, macOS doesn't need a customized kernel build, it just works of the box.

This is the typical answer, "Linux can do that, just need a special customised build and change a couple of config files and /proc settings on boot".

This is not the same as what a standard kernel for consumer OS is supposed to be out of factory.

You are mixing up capabilities with inconvenience.

Then one wonders why Linux will never matter on the desktop, regardless of what Apple and Microsoft might do.

Regular people aren't compiling kernels.

Regular people aren't compiling kernels, they're installing something like Ubuntu Studio (https://ubuntustudio.org/) that comes with everything you need preconfigured out of the box.

Regular people also don't install on OS distribution either, they buy a laptop/desktop system.

You're mixing up capabilities with extra work with capabilities with no work.

If OS X also had tailor made kernel just for lower real time latency it could do even better.

But out of box, it's already better.

That said, the point is moot. 99% of pro audio/MIDI apps/VSTs don't run on Linux, so only experimental nerdy musicians and FOSS zealots would use it for real studio work. You do get the occasional profile on music tech websites e.g. "Techno musician X uses Linux", and somebody always jumps in a forum to say they use some Linux DAW (and usually add a list of ugly hacks, workarounds, and things that don't work), but it's clearly a total outlier situation...

Something something real world enterprise solution. Big megacorp using Dells everywhere with Windows. Bla bla bla.

Something something snark missing the point.

Nobody said Linux can't for some law of nature run music software.

But it's empirically true that it both lacks 99% of music software people want to run, and that it's not used by 99% of musicians...

It's easier to load a real-time kernel in Debian than it is to install nvidia drivers.

I haven't done it in a few years but a quick google search says that it's as simple as: apt-get install linux-image-rt-amd64 on Debian.

Hell it's probably easier to load a real-time kernel in Debian than it is to install video card drivers on any other operating system. T

Simple while showing up shell commands don't combine for the crowd I am speaking of.

You were not speaking of a crowd in your original statement:

> Regarding performance, on the other hand Linux/BSD still don't match macOS real time audio capabilities.

It's better to say that you were wrong at this point then to try to shift yr statement to a popularity contest instead of the soft-realtime latency contest you, YOU, started with.

They don't match, because I have been pointed out in this thread that I need to either install a special kernel version, go hunt for a customized Ubuntu version or compile a customized kernel.

The macOS kernel doesn't require any of this, it just works.

No audio professional using Apple hardware needs to learn these workarounds to actually do their work.

> No audio professional using Apple hardware needs to learn these workarounds to actually do their work.

You keep repeating this. But no one said this is not the case.

That seems pretty patronizing of that "crowd". Is the topic of this thread (the top-level, not the topic of audio latency) something that matters to that crowd you represent?

The topic is audio latency and keeping with the kernel that OS vendor ships.

Only change allowed is installing drivers during user friendly tooling that any random user that just got their first laptop today is able to do.

Failure to understand this, is why we are getting Year of Desktop Linux any day soon.

Naturally there are other areas that BSD/Linux do better out-of-the-box, without requiring customized kernels.

How about “install linux-image-rt-amd64 using the debian package manager GUI” then?

(Not at a debian box to look up the start menu item name, and I don’t use the GUI these days...)

I don’t have to google to know how to install video card drivers

No, you just have to go to the Nvidia website and fuck around for 5 minutes with nested lists of devices and models and shit the average user probably has no idea about just to download some incredibly huge download full of over complicated software that no one will ever use.

At least this is how it has been every single time that I've installed an Nvidia driver on windows.

I stand by my position, it is easier, and trivial to install a real-time kernel in Debian than it is to install an Nvidia driver in Windows.

And if an audio professional can't be bothered to figure this out to make money while a teenaged gamer can figure out an Nvidia driver just to play games then they should maybe consider changing professions because this trivial roadblock will be the least of their technical worries in the audio world.

Your statement was that audio latency is lower on OSX compared to Linux, and you cannot back that up. We all know that the prevalence of Linux DAWs in the studios are low. But that would only be related to OSX having the lowest latency if latency was the only thing that ever mattered to professional studios. Which it’s not.

Try to do the same with a standard Linux distribution kernel, without customisation.

Why? The goalposts you've erected are entirely arbitrary and unnecessary.

Because that is what regular users care about, they are not nerds compiling kernels to achieve what is supposed to be a factory enabled capability.

My point stands, macOS kernel doesn't need to be compiled from scratch to achieve that.

Ubuntu Studio doesn't need to be compiled from scratch to achieve it either..

The applications that most professionals involved in music and audio use don't run on Linux. And with most professionals the application and it's stable running is the key concern, the OS just facilitate the application.

Why do you think any compiling whatsoever is involved?

Ubuntu Studio doesn't need to be compiled from scratch either, but easily provides better performance specs than MacOS out of the box.

They are goal posts the vast majority of ordinary users have to deal with every day, whether you or they like where they are located or not.

This seems to be an odd position to take in a thread about kernel extensions given that they're a fairly esoteric feature that power users make use of.

But 'power users' and 'audio professionals' aren't necessarily the same people.

They're fairly common on the Mac, even for average users. A 3G mobile network dongle I got from Virgin Mobile required a kernel extension to run on my Mac.

Of course, years later I'd be much more hesitant to install a required networking Kernel Extension from an organisation called "Huawei".

Regular distro with "no custom kernel" is an arbitrary goalpost?

When talking about what musicians will use?

There's def a crowd using Ubuntu studio.

Ubuntu Studio user checking in .. REAPER on Ubuntu Studio is simply the highest performing DAW around. Nothing comes close.

The comment above this one says:

> I ... get less latency now. Especially because I can run a real-time kernel...

Where does it say they needed the real-time kernel to match macOS? It says "especially because", not "exclusively because". No data is shared on precisely how suitable it was or wasn't before the kernel tweaks.

Especially because does imply that.

"It was acceptable before but it is especially good after kernel tweaks" is a perfectly valid reading of that sentence.

Did you know that some hardware mixing desks being sold for live concerts and TV broadcasts are actually 2 Linux systems in a box?

Professional audio producers and musicians can just as easily gain a high-performance DAW by using Ubuntu Studio, out of the box. My system thus configured, runs REAPER far better than the MacBook or Windows machines that are in the studio for the same purposes.

I wouldn't say it's easier, but you can achieve more deeply tailored audio environments with Linux than with macos. I have a friend who is able to run a vector of 4 samples on Manjaro with the high perf rt kernel and using alsa backend. This is impossible to achieve on macos without significant hacking or maybe one of the new workstations. Even then...

Like others, I'm finding that audio latency on Linux surpasses that of MacOS, easily. I am using Ubuntu Studio with Firewire-based audio interfaces, 50+ channels of digital audio - Linux definitely performs better than my MacOS systems, using the exact same external hardware .. except my Linux box is slower and has fewer cores than my MacBook ..

> Are there any details about DriverKit that are available?

Yes, they're on the documentation site. Here's NetworkingDriverKit:

https://developer.apple.com/documentation/networkingdriverki...

With the fancy new userspace networking stack, I wouldn't assume that a DriverKit implementation is necessarily slower. At least compared to the old networking stack.

(It says it's meant to be used "to develop drivers for USB Ethernet adapter", but I don't believe there's anything specifically tying it to USB. DriverKit currently doesn't support PCI access; I don't know if that's coming, but the PCI APIs for kexts are not deprecated, so at minimum you could write a kext just to map the device into userspace.)

PCI access is apparently coming in the March release.

Yes DriverKit allows writing network card drivers.

I was toying with trying to port the Linux Mellanox ConnectX drivers to macOS to avoid having to pay 2-3x the price for ATTO FastFrame cards. You need a special entitlement from Apple to sign network csrd drivers though.

FWIW I can only get about 60Gbps out of the ATTO FastFrame on macOS versus easily 98Gbps for Mellanox ConnectX on Linux.

It's perhaps worth noting that macOS already has drivers for at least one 10Gb chipset, since 10Gb interfaces are present on the Mac Pro and iMac Pro, and an option on the Mac Mini.

You may find this useful to consider as well as the dev links above: https://news.ycombinator.com/item?id=22251991

Interesting that even the $6000+ Mac Pro only has 2006 era Ethernet.

Reply on news.ycombinator.com