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

21–30 of 54 posts

Re: FreeBSD Audio

#21

Post by rabf »

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…

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.

Re: FreeBSD Audio

#22

Post by tialaramex »

bluGill wrote: post #4
rijoja wrote: post #2

How does this compare to other platforms such as Windows or Mac?

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

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

Re: FreeBSD Audio

#23

Post by twic »

0mp wrote: post #3

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

Consistent with what jwz described as the "CADT" model of development.

Re: FreeBSD Audio

#24

Post by michaelmrose »

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?

Re: FreeBSD Audio

#25

Post by bluGill »

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…

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.

Re: FreeBSD Audio

#26

Post by odiroot »

bluGill wrote: post #13
marcodiego wrote: post #6

Earlier quoted context omitted.

AFAIK, pipewire is also a drop-in replacement do jack, right?

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.

Re: FreeBSD Audio

#27

Post by chungy »

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…

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

Re: FreeBSD Audio

#28

Post by johnr2 »

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?

Re: FreeBSD Audio

#29

Post by Fnoord »

chungy wrote: post #27
throw0101a wrote: post #16

Earlier quoted context omitted.

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

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

Re: FreeBSD Audio

#30

Post by Fnoord »

0mp wrote: post #3

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

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

Post reply on HN