I just skimmed over it but it looks like an interesting article. One thing the solution doesn't seems to be is simple or easy to use. Pipewire seems to be fixing the last remaining linux problems with multimedia, it is already a reasonable low latency kernel and will probably soon become even better once PREEMPT_RT finally lands. By coming by default on most popular distros, I hope using it will be invisible or simple too.
Nevertheless, as a linux user, I envy some features. I had apt break recently in a way that took 5 hours to fix with help from the people at #debian at oftc. A stable, mature and high performant filesystem with snapshots is badly needed. It could have reduced my time to a working apt again from hours to minutes.
When I was using apt based distros, Debian, Ubuntu, apt and dpkg would break all the time as soon as you went a little bit out of the canonical usage. In contrast I have yet to see Arch's pacman fail anywhere, even when used in non-ArchLinux places such as MSYS2
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.
Checksums and snapshots are so valuable I don't care about the performance impact. Modern file systems use more medatada so I expect them to be slower in metadata intensive operations, and the COW approach isn't good for every workload.
> Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.
Not quite true IMHO. One of best features of ZFS is checksumming to ensure data integrity, where errors can be corrected if you have enough redundancy.
You certainly lose this feature with single disks, but you're not necessarily worse off than any other file system.
What ZFS gives you on a single disk is very convenient snapshots and very convenient (incremental) streaming of those snapshots to another system (via either a push or pull mechanism). Doing this with other file systems generally entail a lot more work and much less efficiency. btrfs can do it, but if you're using ext4, then you'll probably use rsync which has to walk the file tree to find changed files.
Also with ZFS and snapshots you can turn them into clones: writable copies. This allow boot environments were updates/upgrades can be done, and if things do not work out, you can boot back to the original setup:
From using ZFS since ~2008, I have only ever lost one ZFS pool, and it was due to lack of scrubs (the array was created on a FreeBSD version before ZFS was integral to the installer, and despite upgrades the nightly scripts just never got overwritten, so the array was never scrubbed).
I can't say I've never lost an ext4 partition either, but I've never lost one under normal use without some sort of weird hardware issue causing data corruption.
By definition, without a redundant copy of the data the scrub can't fix anything.
> Creating a pool with no redundancy is not recommended...
You can also have datasets on a single disk where copies can be set to 2 or more so that checksum errors can be recovered. Each dataset in zfs can have a wealth of options such as compression that are specific to them.
Booting with a Live CD (recently USB flash drive), can have you back up and running in 15 mins or so. Even doing the install that replaces /usr etc only takes 30-40 or so.
From the article: "I started using FreeBSD in 2016 as a dual-boot with Linux. The reason was that at the time Linux provided no support for real-time threads and preemptive scheduling"
I've been using real time threads and preemptive scheduling on my Linux audio workstations since 2005. Am I missing something here, or is that date in the article a typo?
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.
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.
I remember using the OSS drivers and even paying for the commercial version at one point. The experience was great, and I hated it because it was a repudiation of Open Source, which was a big part of my identity back then. I had sold out to the man for working audio… but work it did.
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.
Oh, yes, certainly my comment about selling out to the man was made tongue-in-cheek, poking fun at my younger self and how very serious I was about these things in the past. I am happy to see OSS earn some money for their efforts, even if my general personal disposition is still for open source.
I was a bit surprised to hear they are still a business in 2021. I see they are still releasing OSS and much of it under a GPL license too. I gather their OSS product customers must have some specialist sound system requirements for Linux / FreeBSD.
With ALSA, Pulseaudio, and now Pipewire there's not much point really; maybe it's better but that ship has sailed, on Linux anyway. It's become VHS vs. Betamax-kind of lamenting.
4Front seems to be working on https://www.truepianos.com now; though that one's not open source and no Linux version either.
I don't have an account on Lobsters so I can't comment there, but that comment is pretty awful and includes some revisionist history nonsense. The author seriously has their timeline mixed up and doesn't seem to be aware of what actually happened in Linux land, so I would take everything they say with a grain of salt. I have no idea why Linux audio seems to invite so much FUD.
"A bit later, a new version of OSS came out, OSS 4, which was not released as open source. The Linux developers had a tantrum and decided to deprecate OSS and replace it with something completely new: ALSA."
This is blatantly false. ALSA begun development in 1998 because of missing features in the OSS API [1], in terms of both drivers and userspace. OSSv4 was not released until 9 years later in 2007 [2]. Various other Linux developers have also expressed unhappiness with deficiencies in the OSS API [3]. Whichever tantrum is being talked about here seems to be wholly fictional.
"Meanwhile, the FreeBSD team just forked the last BSD licensed OSS release and added support for OSS 4 and in-kernel low-latency sound mixing..."
This entire paragraph makes no sense to me and has nothing to do with OSSv4. Announcement of an OSSv4 compatible API didn't happen until 2006 [4], which is well into the FreeBSD 6.x series.
"It was several years before audio became reliable on Linux again and it was really only after everything was, once again, rewritten for PulseAudio. Now it’s being rewritten for PipeWire."
This makes no sense. Applications that were written with basic ALSA/OSS support just worked if they used the Pulseaudio PCM. Applications that used ESD or aRts had issues, but you had the same problems on BSD if you wanted to use GNOME or KDE. Also, Pipewire is explicitly backwards compatible with PulseAudio, so nothing is being rewritten.
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.
Indeed, the author of that comment seems to be confusing OSSv4 with Cameron Grant's newpcm, which was a separate thing. It was developed around the same time as ALSA but didn't have a new userspace API like ALSA and OSSv4 did.
> 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...
"The notion that PulseAudio's introduction wasn't highly disruptive to end users is completely ahistorical."
I never said it wasn't, there were plenty of bugs in
PulseAudio. Please make sure not to argue straw men. The statement I have an issue with is claiming that disruption was caused by apps needing to be rewritten for PulseAudio, which was most likely not the case. PulseAudio even had a compatibility mode for ESD for a while, which stuck around until all the ESD code was removed from GNOME. So that particular aspect wasn't disruptive to end users, it sounds like you're talking about some other bugs.
But on that note, this complaining about bugs in PulseAudio and systemd and such is pretty boring to me because it's making a comparison to some situation that never existed. The situation with bugs and missing features in ESD, NAS and aRts was much worse than PulseAudio, and those projects are all dormant. Likewise with upstart and OpenRC.
> The statement I have an issue with is claiming that disruption was caused by apps needing to be rewritten for PulseAudio,
There's not any doubt about that. Things were broken all over the place until they were patched. It was awful.
> which was most likely not the case.
It's weird that you're writing as if this was a hypothetical period that human beings did not actually live through, such that we can only speculate about it.
XMMS supported ALSA via a plugin. XMMS was dead anyway, at that point (when ALSA arrived). It had a GTK1 interface, for example, and barely got updates. At some point, the plugin ecosystem was more alive than XMMS itself, and they extended the software a lot (think of it like Sublime Text's plugin system, or Winamp's). XMMS2 took way too long to arrive. In the meantime, better iTunes-like audio players were released, such as the ones default in GNOME and KDE.
The post also fails to mention JACK, a low latency audio server for Linux. Which is now replaced by PipeWire. JACK was programmed by the same person as Ardour, called Paul Davis. You might've seen him around here. He's been doing using Linux audio professionally for a while.
There was also a Linux live distribution aimed for being used as a Linux audio workstation, called dyne:bolic.
FreeBSD was and is a niche, not the reason why Linux wasn't used much for professional audio work.
The ALSA debacle was a short lasting transition period (eventually ALSA even got OSS emulation).
The reason why Linux wasn't used much for professional audio work goes to Apple. macOS is just easier to use than any Linux distribution, so it got the momentum in that scene (and in the artistic scene in general). The rest is history.
>it is the same if sound is late 5 seconds or 1 second
Assuming there is no video, or the video can be delayed to stay in sync. And it also matters for other real time stuff such as gaming. I suppose most desktop stacks are good enough for gaming, but that's something current Bluetooth audio is unusable for.
What is a good way to benchmark the various different operating systems and sound systems to establish the difference in latency? Anyone aware of a good write up of same?
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). For normal users it is good enough, but if you are a musician then it doesn't work well without programs that support the other standard.
Linux does similar things with pipewire/jack. Pipewire is still in the early days so has growing pains. The problem with both is they are not part of the OS so your program needs to be written to handle it (but these days almost all programs use pulseaduio which pipewire implements). This can route any program to any program/output at the OS level, though mixing Jack and pulseaudio APIs is probably a pain. Jack has some nice GUIs for sound routing, I don't know if any exist for this.
The effort is nice to see, but unless they support the jack APIs I think most people will be using jack on freebsd anyway for the near future. On the other hand, this is what Linux should have done all along. Linux has consistently done sound wrong going back to 2003 when they did ALSA instead of fixing OSS.
> 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)
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...
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.
They've been saying that they improve things and WASAPI for every version since Vista but it still does not performs as well as ASIO (and ASIO is muuuch more simple for the audio application developper than this WASAPI hellhole...)
It works better for me than the original jack2. I also use multiple USB "sound cards" and that workflow is painful with JACK. In Pipewire they all share the same space and I can use them in a DAW at the same time.
Real time thread support is very mature in Darwin. Currently there is no audio stack peer on any platform that can compare with Apple's CoreAudio in terms of latency and audio chain generality.
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.
Nevertheless, as a linux user, I envy some features. I had apt break recently in a way that took 5 hours to fix with help from the people at #debian at oftc. A stable, mature and high performant filesystem with snapshots is badly needed. It could have reduced my time to a working apt again from hours to minutes.