7 ms·

FreeBSD Audio

123 points by 0mp 5y ago

rijoja 5y ago
How does this compare to other platforms such as Windows or Mac?
- bluGill 5y ago
  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.
  - marcodiego 5y ago
    AFAIK, pipewire is also a drop-in replacement do jack, right?
    - bluGill 5y ago
      Yes, but it is immature enough that it isn't recommended for low latency audio yet.
      - odiroot 5y ago
        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 5y ago
        YMMV. The pipewire developers say it isn't ready for that yet, but it works well for some.
  - laumars 5y ago
    > 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 https://en.m.wikipedia.org/wiki/Audio_Stream_Input/Output
  - ryuuchin 5y ago
    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/audio/low-latency-audio https://docs.microsoft.com/en-us/windows-hardware/drivers/au...
    - jcelerier 5y ago
      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 5y ago
    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...
- waffletower 5y ago
  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 5y ago
    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.
0mp 5y ago
There is an interesting comment to this article on Lobsters: https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_happy#c_mqvroo https://lobste.rs/s/moflv5/freebsd_audio_from_perspective_ha...
- peatmoss 5y ago
  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.
  - arp242 5y ago
    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.
    - peatmoss 5y ago
      Oh, yes, certainly my comment about selling out to the man was made tongue-in-cheek, poking fun at my younger self and how very serious I was about these things in the past. I am happy to see OSS earn some money for their efforts, even if my general personal disposition is still for open source. I was a bit surprised to hear they are still a business in 2021. I see they are still releasing OSS and much of it under a GPL license too. I gather their OSS product customers must have some specialist sound system requirements for Linux / FreeBSD.
      - arp242 5y ago
        I'm not sure if they're really "in business" as such; it gets some very occasional updates for new kernels (last release: 2019), but that's about it. See e.g.: http://ossnext.trueinstruments.com/forum/viewtopic.php?f=16&t=5838&p=21618#p21618 http://ossnext.trueinstruments.com/forum/viewtopic.php?f=16&... With ALSA, Pulseaudio, and now Pipewire there's not much point really; maybe it's better but that ship has sailed, on Linux anyway. It's become VHS vs. Betamax-kind of lamenting. 4Front seems to be working on https://www.truepianos.com https://www.truepianos.com now; though that one's not open source and no Linux version either.
marcodiego 5y ago
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 5y ago
  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.
- dTal 5y ago
  I am curious what your objections are to btrfs and ZFS? I know of some common ones, but I want to hear yours.
  - marcodiego 5y ago
    AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.
    - diegocg 5y ago
      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 5y ago
      Depends. ZFS mirrors are very snappy. Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.
zokier 5y ago
This is first time I've heard that freebsd has good rt. Are there any good benchmarks or something comparing it to preempt_rt?
LinAGKar 5y ago
>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.
michaelmrose 5y ago
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 5y ago
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?
- codetrotter 5y ago
  Maybe they meant that the distro they use didn’t have it enabled in the kernel?
- zokier 5y ago
  Presumably not on mainline kernel. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70e6e1b971e46f5c1c2d72217ba62401a2edc22b 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/ https://lwn.net/Articles/867821/
  - Sesse__ 5y ago
    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.
  - johnr2 5y ago
CodeArtisan 5y ago
This picture was popular on 4chan a few years ago: https://imgur.com/a/ZyNZ0JL https://imgur.com/a/ZyNZ0JL

FreeBSD Audio

123 points by 0mp 5y ago

rijoja 5y ago

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

bluGill 5y ago
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.
- marcodiego 5y ago
  AFAIK, pipewire is also a drop-in replacement do jack, right?
  - bluGill 5y ago
    Yes, but it is immature enough that it isn't recommended for low latency audio yet.
    - odiroot 5y ago
      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 5y ago
        YMMV. The pipewire developers say it isn't ready for that yet, but it works well for some.
- laumars 5y ago
  > 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 https://en.m.wikipedia.org/wiki/Audio_Stream_Input/Output
- ryuuchin 5y ago
  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/audio/low-latency-audio https://docs.microsoft.com/en-us/windows-hardware/drivers/au...
  - jcelerier 5y ago
    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 5y ago
  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...
waffletower 5y ago
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 5y ago
  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.

0mp 5y ago

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

peatmoss 5y ago
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.
- arp242 5y ago
  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.
  - peatmoss 5y ago
    Oh, yes, certainly my comment about selling out to the man was made tongue-in-cheek, poking fun at my younger self and how very serious I was about these things in the past. I am happy to see OSS earn some money for their efforts, even if my general personal disposition is still for open source. I was a bit surprised to hear they are still a business in 2021. I see they are still releasing OSS and much of it under a GPL license too. I gather their OSS product customers must have some specialist sound system requirements for Linux / FreeBSD.
    - arp242 5y ago
      I'm not sure if they're really "in business" as such; it gets some very occasional updates for new kernels (last release: 2019), but that's about it. See e.g.: http://ossnext.trueinstruments.com/forum/viewtopic.php?f=16&t=5838&p=21618#p21618 http://ossnext.trueinstruments.com/forum/viewtopic.php?f=16&... With ALSA, Pulseaudio, and now Pipewire there's not much point really; maybe it's better but that ship has sailed, on Linux anyway. It's become VHS vs. Betamax-kind of lamenting. 4Front seems to be working on https://www.truepianos.com https://www.truepianos.com now; though that one's not open source and no Linux version either.

marcodiego 5y ago

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 5y ago
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.
dTal 5y ago
I am curious what your objections are to btrfs and ZFS? I know of some common ones, but I want to hear yours.
- marcodiego 5y ago
  AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.
  - diegocg 5y ago
    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 5y ago
    Depends. ZFS mirrors are very snappy. Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.

zokier 5y ago

This is first time I've heard that freebsd has good rt. Are there any good benchmarks or something comparing it to preempt_rt?

LinAGKar 5y ago

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

michaelmrose 5y ago

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 5y ago

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?

codetrotter 5y ago
Maybe they meant that the distro they use didn’t have it enabled in the kernel?
zokier 5y ago
Presumably not on mainline kernel. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70e6e1b971e46f5c1c2d72217ba62401a2edc22b 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/ https://lwn.net/Articles/867821/
- Sesse__ 5y ago
  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.
- johnr2 5y ago

CodeArtisan 5y ago

This picture was popular on 4chan a few years ago: https://imgur.com/a/ZyNZ0JL https://imgur.com/a/ZyNZ0JL