There is an interesting comment to this article on Lobsters: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...
Although details differ, all of this is still not really a solved problem today. People want to have their cake and eat it too.
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.
"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.
[1] https://www.linuxjournal.com/article/8234
[2] http://ossnext.trueinstruments.com/forum/viewtopic.php?f=19&...
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.
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.
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...
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.
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.
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.