This is first time I've heard that freebsd has good rt. Are there any good benchmarks or something comparing it to preempt_rt?
FreeBSD Audio
11–20 of 54 posts
Re: FreeBSD Audio
#12There 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.
Re: FreeBSD Audio
#13Earlier quoted context omitted.
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…
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.
Re: FreeBSD Audio
#14I 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
Re: FreeBSD Audio
#15Earlier quoted context omitted.
I am curious what your objections are to btrfs and ZFS? I know of some common ones, but I want to hear yours.
AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.
Depends. ZFS mirrors are very snappy.
Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.
Re: FreeBSD Audio
#16Earlier quoted context omitted.
AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.
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 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...
Re: FreeBSD Audio
#17I 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…
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.
Re: FreeBSD Audio
#18Earlier quoted context omitted.
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…
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...
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...)
Re: FreeBSD Audio
#19Earlier quoted context omitted.
I am curious what your objections are to btrfs and ZFS? I know of some common ones, but I want to hear yours.
AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.
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.
Re: FreeBSD Audio
#20>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.