31–40 of 54 posts
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?
How does this compare to other platforms such as Windows or Mac?
There is an interesting comment to this article on Lobsters: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...
"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&...
How does this compare to other platforms such as Windows or Mac?
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.
Earlier quoted context omitted.
Yes, but it is immature enough that it isn't recommended for low latency audio yet.
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.
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?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Heck, there are still major parts of RT Linux being released in the upcoming kernel:
There is an interesting comment to this article on Lobsters: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...
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…
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.
There is an interesting comment to this article on Lobsters: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...
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…
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.
Earlier quoted context omitted.
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…
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…