FreeBSD Audio

AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.

Interestingly I have the exact opposite experience. Apt has never failed for me in the last 15 years but pacman fails all the time in both Arch derivatives and specially in MSYS2. With pacman you HAVE to keep updating at least weekly. MSYS2 often gets into state where it will no longer download updates and after going through all suggested fixes the only thing that works is to nuke it and start fresh. It doesn't help that pacman is designed to be used interactively so you can't just schedule reliable background updates.

Linux has had real-time threads (round-robin and, more recently, deadline scheduling) and kernel preemption for a _long_ time. But the kernel isn't fully preemptible all the time, and latencies are not strictly bounded in all such situations (e.g. if you are trying to grab a contested spinlock). PREEMPT_RT is the final icing on the cake, and as far as I know, it makes Linux the first general-purpose OS that has full realtime guarantees.

But I haven't been able to figure out anything that would indicate FreeBSD is better (or is better than what Linux was in 2016). The information is sparse, but it seems to me that it has a scheduler with _some_ support for realtime threads (when the timeslice is up, RT threads take priority in the scheduling algorithm), but not really preemption of non-RT threads by RT threads (ie., when a RT thread is ready to wake up, non-RT threads get kicked out even if the timeslice isn't up), and I cannot find anything at all about the kernel being preemptable by userspace threads, RT or not.

> Presumably not on mainline kernel.

At first it was necessary to compile the realtime-lsm module to allow user programs to make use of realtime scheduling. In late 2006 or so (IIRC) rlimits-aware PAM became available which made realtime-lsm redundant.

I've used CONFIG_PREEMPT=y (along with CONFIG_HZ=1000) when compiling mainline kernels all along. My current distro of choice (Void) enables these by default in their 5.4 series kernels. I've never needed PREEMPT_RT for my particular use case.

AFAIK FreeBSD still doesn't allow users to run programs with realtime scheduling privileges (SCHED_FIFO or SCHED_RR), only root.

Considering that OSS was (and still is) run by just a few people and is a small company, I don't think it's "selling out to the man"; it's not Microsoft or Amazon or anything. They tried to be as "open source as possible" while still ensuring they've got money to it. I don't think anyone got very rich from it.

Although details differ, all of this is still not really a solved problem today. People want to have their cake and eat it too.

It amazes me how much time has passed since then. I would have to go and look up the history and events to remember what order things happened.

However, with my FreeBSD hat on, it should be pointed out that we had this wonderful fellow called Cameron Grant. He is largely responsible for FreeBSD's post-OSS audio system. FreeBSD could have gone several ways for audio at the time, but he made it work, and it worked well. It had virtual channels with in-kernel mixing with very low latency - with full API compatibility. Tragically, Cameron's time was cut short.

Over time, other people got involved and picked it up. The subsystem gradually progressed from the user perspective of being simple and Just Working, to something that is rather powerful today.

> Various other Linux developers have also expressed unhappiness with deficiencies in the OSS API [3].

Wanted to see what this meant so i read the citation. I think this is what I found most relevant:

> There are two separate models that can be used between the software and the hardware. In a "push" model, the application decides when to read or write data and how much, while the "pull" model reverses that, requiring the hardware to determine when and how much I/O needs to be done. Supporting a push model requires buffering in the system to smooth over arbitrary application behavior. The pull model requires an application that can meet deadlines imposed by the hardware.

The claim is that write(2) etc. is supporting push but ill suited for pull. It's easy to do the former in terms of the latter but not the other way around.

The notion that PulseAudio's introduction wasn't highly disruptive to end users is completely ahistorical. People were pretty pissed off about it, and not because something changed under the covers in a totally seamless and trouble-free way.

I sort of felt for Lennart Poettering for all the abuse [0] he got (I guess it helped that I'd already given up on using Linux as a desktop, so it could be as broken as it wanted to be as far as I was concerned) until he inflicted systemd on the world...

[0] http://0pointer.de/blog/projects/jeffrey-stedfast.html

AFAIK, pipewire is also a drop-in replacement do jack, right?

> Windows audio has never made working with latency or routing sound between programs a goal. There are ways to do it, but isn't in the default. (I forget what it is called, but there is a common standard - starts with an A)

ASIO

https://en.m.wikipedia.org/wiki/Audio_Stream_Input/Output

They've improved things in Windows 10[1] with driver support(?) apparently although I have no experience with this so I can't say how this affects things practically.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/au...

Rather than force my preference on their IT hardware people while they're still dealing with knock-on effects from a pandemic, the laptop my current employer provided runs Windows because that's their default.

A few times per week, Windows will inform me "Your speakers aren't working" or "Your microphone isn't working". Notice that this is deliberately vague as to agency or cause even though of course they couldn't detect if the actual problem was that the physical microphone or speakers wasn't working. They know it isn't working because their driver fell over even though they don't admit that's the problem. As a result rebooting the computer usually fixes it.

Now, I happen to own a laptop by the same vendor, into which I can plug the exact same devices, and on that laptop these audio devices work reliably even under Windows (which is installed to run some games). But "it works on some hardware and not others" is exactly the sort of poor user experience Linux (and *BSD) audio gets dinged for...

BeOS and Haiku OS would give your latency claims a run for its money. The node based architecture allows piping and chaining as well. Disclaimer - I wrote a media (audio/video) editor for Haiku.