[HN Gopher] FreeBSD Audio
___________________________________________________________________
FreeBSD Audio
Author : 0mp
Score : 114 points
Date : 2021-10-13 10:38 UTC (12 hours ago)
(HTM) web link (meka.rs)
(TXT) w3m dump (meka.rs)
| 0mp wrote:
| There is an interesting comment to this article on Lobsters:
| https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...
| Fnoord wrote:
| 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.
|
| [1] https://en.wikipedia.org/wiki/Dyne:bolic
| md8z wrote:
| 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.
|
| [1] https://www.linuxjournal.com/article/8234
|
| [2]
| http://ossnext.trueinstruments.com/forum/viewtopic.php?f=19&...
|
| [3] https://lwn.net/Articles/355542/
|
| [4] https://wiki.freebsd.org/RyanBeasley
| darkhelmet wrote:
| 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.
| md8z wrote:
| 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.
| asveikau wrote:
| > 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.
| twic wrote:
| Consistent with what jwz described as the "CADT" model of
| development.
| peatmoss wrote:
| 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.
| LinAGKar wrote:
| >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.
| zokier wrote:
| This is first time I've heard that freebsd has good rt. Are there
| any good benchmarks or something comparing it to preempt_rt?
| marcodiego wrote:
| 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.
| bluGill wrote:
| An adaptor so that jack/pipewire control programs can work with
| this would be a useful addition. I have no idea how to design
| on though.
| jcelerier wrote:
| 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
| dmz73 wrote:
| 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.
| mixmastamyk wrote:
| 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.
| dTal wrote:
| I am curious what your objections are to btrfs and ZFS? I know
| of some common ones, but I want to hear yours.
| marcodiego wrote:
| AFAIK, both btrfs and zfs are still slower than ext4 for most
| desktop use cases.
| diegocg wrote:
| 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.
| RNCTX wrote:
| Depends. ZFS mirrors are very snappy.
|
| Single disks were never a recommended option for ZFS, it's
| a filesystem designed for arrays.
| throw0101a wrote:
| > _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:
|
| * https://mwl.io/archives/2363
|
| * https://vermaden.wordpress.com/2021/02/23/upgrade-
| freebsd-wi...
| chungy wrote:
| Probably even more crucial, setting compression=on is
| very likely to make ZFS performance even better than
| ext4, even on a single disk.
| Fnoord wrote:
| This and encryption seem mutually exclusive (for me with
| OpenZFS @ Ubuntu 21.04).
| throw0101a wrote:
| They occur at different layers:
|
| > _OpenZFS native encryption splits the difference: it
| operates atop the normal ZFS storage layers and therefore
| doesn 't nerf ZFS' own integrity guarantees. But it also
| doesn't interfere with ZFS compression--data is
| compressed prior to being saved to an encrypted dataset
| or zvol._
|
| * https://arstechnica.com/gadgets/2021/06/a-quick-start-
| guide-...
| chungy wrote:
| No, they are not. Compression happens on the plaintext
| data, and encryption applies post-compression.
| rabf wrote:
| 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.
| michaelmrose wrote:
| 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?
| johnr2 wrote:
| 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?
| zokier wrote:
| Presumably not on mainline kernel.
|
| 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:
|
| https://lwn.net/Articles/867821/
| codetrotter wrote:
| Maybe they meant that the distro they use didn't have it
| enabled in the kernel?
| rijoja wrote:
| How does this compare to other platforms such as Windows or Mac?
| waffletower wrote:
| 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.
| smallstepforman wrote:
| 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.
| bluGill wrote:
| I'm not sure about Mac.
|
| 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.
| laumars wrote:
| > _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
| ryuuchin wrote:
| 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...
| jcelerier wrote:
| 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...)
| tialaramex wrote:
| 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...
| marcodiego wrote:
| AFAIK, pipewire is also a drop-in replacement do jack, right?
| bluGill wrote:
| Yes, but it is immature enough that it isn't recommended
| for low latency audio yet.
| odiroot wrote:
| 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.
| bluGill wrote:
| YMMV. The pipewire developers say it isn't ready for that
| yet, but it works well for some.
| CodeArtisan wrote:
| This picture was popular on 4chan a few years ago:
| https://imgur.com/a/ZyNZ0JL
___________________________________________________________________
(page generated 2021-10-13 23:01 UTC)