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