Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FreeBSD Audio

meka.rs

Post reply on HN
Print view View original

41–50 of 54 posts

Re: FreeBSD Audio

#41

Post by throw0101a »

Fnoord wrote: post #29
chungy wrote: post #27

Earlier quoted context omitted.

Probably even more crucial, setting compression=on is very likely to make ZFS performance even better than ext4, even on a single disk.

This and encryption seem mutually exclusive (for me with OpenZFS @ Ubuntu 21.04).

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-...

Re: FreeBSD Audio

#42

Post by chungy »

Fnoord wrote: post #29
chungy wrote: post #27

Earlier quoted context omitted.

Probably even more crucial, setting compression=on is very likely to make ZFS performance even better than ext4, even on a single disk.

This and encryption seem mutually exclusive (for me with OpenZFS @ Ubuntu 21.04).

No, they are not. Compression happens on the plaintext data, and encryption applies post-compression.

Re: FreeBSD Audio

#43

Post by dmz73 »

jcelerier wrote: post #14
marcodiego wrote: post #5

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 simpl…

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.

Re: FreeBSD Audio

#44

Post by arp242 »

peatmoss wrote: post #12
0mp wrote: post #3

There is an interesting comment to this article on Lobsters: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...

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.

Re: FreeBSD Audio

#45

Post by RNCTX »

throw0101a wrote: post #16
RNCTX wrote: post #15

Earlier quoted context omitted.

Depends. ZFS mirrors are very snappy. Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.

> 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 sn…

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...

https://docs.oracle.com/cd/E26502_01/html/E36219/storage-4.h...

Re: FreeBSD Audio

#46

Post by jcelerier »

dmz73 wrote: post #43
jcelerier wrote: post #14

Earlier quoted context omitted.

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…

> With pacman you HAVE to keep updating at least weekly

My record is updating a machine that was off for two years lol, it worked from the first try

Even for msys, I find that weird, I boot on win32 ... Once a month maybe ? And msys updates do work. Wild.

Re: FreeBSD Audio

#47

Post by justin66 »

md8z wrote: post #34
0mp wrote: post #3

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…

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

Re: FreeBSD Audio

#48

Post by Sesse__ »

zokier wrote: post #37
johnr2 wrote: post #28

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?

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/

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.

Re: FreeBSD Audio

#49

Post by md8z »

justin66 wrote: post #47
md8z wrote: post #34

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…

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…

"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.

Re: FreeBSD Audio

#50

Post by johnr2 »

zokier wrote: post #37
johnr2 wrote: post #28

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?

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/

> 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.

Post reply on HN