3 ms·

Honestly this area is so frustrating technologically. MacOS has easily the best Audio subsystem across MacOS & Windows. In Linux we have JACK, which is as goo

by dijit 4y ago

Honestly this area is so frustrating technologically. MacOS has easily the best Audio subsystem across MacOS & Windows. In Linux we have JACK, which is as good as MacOS (if not better honestly). But then Linux suffers from having very little commercial support and worse than that, a lot of problems with hardware video encoding. Windows doesn't have any problems encoding video, but it has a terrible filesystem (which is forced on you) that causes problems for the insanely large files that you must work with on video production and in addition: the audio subsystem is the worst of all three platforms. Linux could be a contender, if someone threw $100M USD at the problem, but getting adoption for a linux solution would be hard because the Apple stuff works "fine" and movie productions are more time constrained than cost constrained.

viraptor 4y ago
> In Linux we have JACK, which is as good as MacOS (if not better honestly). And now we have Pipewire which is not only better, but can also pretend it's Jack for compatibility.
- jeroenhd 4y ago
  Pipewire still had its issues (mixing setups can easy cause weird sound issues) but it's much better than anything that came before it. I'd go as far as to say Pipewire made connecting to my Bluetooth headphones more reliable on Linux than on Windows, though neither audio stack is particularly good.
ilyt 4y ago
> In Linux we have JACK, which is as good as MacOS (if not better honestly). screams in terror The ideas are great, the realization is jackshit. Sooo much finicky crap that partly also depends of whether your sound output is special enough to work well with it. And trying to make it play nice with pulseaudio is another nightmare. Pulseaudio itself also suffers massively from UI problems, pretty much all non-basic use cases is either mess with configs or "just run a bunch of commands on runtime or every time your USB interface reconnects". Jack at least gets that part right Trying to get some audio interface to be connected properly was... an experience, it just showed in system as one stereo input (it was 2 mono inputs) and 4.0 output (it had 4 separate outs) so there was a good deal of pulseaudio fuckery to run to just split it properly > Linux could be a contender, if someone threw $100M USD at the problem, but getting adoption for a linux solution would be hard because the Apple stuff works "fine" and movie productions are more time constrained than cost constrained. I wonder if someone figuring out how to run the usual tools via Wine/Proton and somehow integrate nicely with pipewire would've been enough...
- dijit 4y ago
  Pulseaudio is so extremely over complicated that it took years of distro maintainers trying to wrangle it into a working default configuration for many people, and it was adopted because ALSA didn’t (but was going to) support multiple inputs to a single output. It is a prime example of short-sighted “just rewrite it then!” Style Behaviours in FOSS and continues to be brought up in conversations about subsystem replacements (such as systemd). Pipewire is a good replacement, but pulseaudio is to JACK what windows movie maker is to Final Cut. It doesn’t deserve to be brought up when talking about professional solutions.
  - ilyt 4y ago
    It really is amalgamation of "whatever works fine as default on Lennart Poettering's private laptop". Hell, I still remember where "sec, I need to restart pulseaudio" was common thing I've read from my colleagues any time they needed to run some voice chat app... ALSA before that wasn't great either, the fact you didn't get any software mixing by default and needed to fuck around with dmix gave way to endless problems with various software, and the fact dmix was still working subtly different than "real" device also reared its ugly head in many "pro audio" apps.
    - dijit 4y ago
      > ALSA before that wasn't great either, the fact you didn't get any software mixing by default It was being developed. People jumped on Pulseaudio and made it the default before it was finished because the ALSA contributers wanted to do it in a way that was either going to work for embedded or be optional in a reasonable way, IE; they were trying to do it right, took too long, and it got replaced with something much worse that did the job. Which, happens unfortunately frequently.
      - yamtaddle 4y ago
        Similar story for how ALSA came to exist, really. Linux folks looked at OSS and said "this blows, let's replace it" and made ALSA. The FreeBSD folks looked at OSS and said "this blows, let's fix it". And did. And they're still on that while Linux is headed into its third major audio shake-up in the same time span (OSS -> ALSA -> PulseAudio -> PipeWire).
alushta 4y ago
dvngnt_ 4y ago
windows still has the audio mixer to beat
- steve1977 4y ago
  Which is why every professional audio tool uses ASIO and every audiophile player is going to great lengths to avoid the audio mixer and uses things like kernel streaming.
chris222 4y ago
Does MacOS even have OS level independent volume control for each app yet?
- brookst 4y ago
  Sort of? The kernel supports this and has forever, but the OS doesn’t ship with an app that exposes the capability. It’s super annoying. There are a number of third party apps, some free, some paid.
- larrik 4y ago
  Not that I've found!
- the_other 4y ago
  Why should the OS solve app problems?
  - dijit 4y ago
    Yeah. Why do we need `open()` anyway? (this is sarcasm, the OS exists only to solve app problems).
- yamtaddle 4y ago
  This was what everyone said was the reason for wrecking Linux with PulseAudio, all those years ago. I've still never cared and don't know why I should. What am I missing? I've used systems with that, but never bothered to try using it because... why would I? Every media player has a volume control, YouTube has a volume control, every game has a volume control (usually multiple, for different types of sound), and 99% of the time I just want everything at about the same level anyway. The last thing I want to do is have another place a given program could have its volume set or muted or whatever, so then I have another place to look when it's not doing what I want. One per-program (built in to the programs) and one global is quite enough.
  - error503 4y ago
    For me it wasn't so much the per-app/stream mixer but per-stream dynamic routing that was the important feature of Pulse (though I've moved on to PW now). I'm not too sure how this is handled on other platforms, but pre-PA the in-app volume control would often modify the global mixer, rather than implement an in-app mixer/attenuator, which is definitely not what you usually want. In most Linux apps these days, those controls manipulate and are synchronized with the PA mixer, so there's still only one actual mixer, they are the same control. I assume that other OSes also do per-stream mixing in a similar manner, and just choose not to expose the mixer for whatever reason. As much as people complain about PulseAudio it's always worked well for me, and from what I've seen of Windows and macOS alternatives, it's more featureful and usable out of the box.

by dijit 4y ago

viraptor 4y ago

> In Linux we have JACK, which is as good as MacOS (if not better honestly). And now we have Pipewire which is not only better, but can also pretend it's Jack for compatibility.

jeroenhd 4y ago
Pipewire still had its issues (mixing setups can easy cause weird sound issues) but it's much better than anything that came before it. I'd go as far as to say Pipewire made connecting to my Bluetooth headphones more reliable on Linux than on Windows, though neither audio stack is particularly good.

ilyt 4y ago

> In Linux we have JACK, which is as good as MacOS (if not better honestly). screams in terror The ideas are great, the realization is jackshit. Sooo much finicky crap that partly also depends of whether your sound output is special enough to work well with it. And trying to make it play nice with pulseaudio is another nightmare. Pulseaudio itself also suffers massively from UI problems, pretty much all non-basic use cases is either mess with configs or "just run a bunch of commands on runtime or every time your USB interface reconnects". Jack at least gets that part right Trying to get some audio interface to be connected properly was... an experience, it just showed in system as one stereo input (it was 2 mono inputs) and 4.0 output (it had 4 separate outs) so there was a good deal of pulseaudio fuckery to run to just split it properly > Linux could be a contender, if someone threw $100M USD at the problem, but getting adoption for a linux solution would be hard because the Apple stuff works "fine" and movie productions are more time constrained than cost constrained. I wonder if someone figuring out how to run the usual tools via Wine/Proton and somehow integrate nicely with pipewire would've been enough...

dijit 4y ago
Pulseaudio is so extremely over complicated that it took years of distro maintainers trying to wrangle it into a working default configuration for many people, and it was adopted because ALSA didn’t (but was going to) support multiple inputs to a single output. It is a prime example of short-sighted “just rewrite it then!” Style Behaviours in FOSS and continues to be brought up in conversations about subsystem replacements (such as systemd). Pipewire is a good replacement, but pulseaudio is to JACK what windows movie maker is to Final Cut. It doesn’t deserve to be brought up when talking about professional solutions.
- ilyt 4y ago
  It really is amalgamation of "whatever works fine as default on Lennart Poettering's private laptop". Hell, I still remember where "sec, I need to restart pulseaudio" was common thing I've read from my colleagues any time they needed to run some voice chat app... ALSA before that wasn't great either, the fact you didn't get any software mixing by default and needed to fuck around with dmix gave way to endless problems with various software, and the fact dmix was still working subtly different than "real" device also reared its ugly head in many "pro audio" apps.
  - dijit 4y ago
    > ALSA before that wasn't great either, the fact you didn't get any software mixing by default It was being developed. People jumped on Pulseaudio and made it the default before it was finished because the ALSA contributers wanted to do it in a way that was either going to work for embedded or be optional in a reasonable way, IE; they were trying to do it right, took too long, and it got replaced with something much worse that did the job. Which, happens unfortunately frequently.
    - yamtaddle 4y ago
      Similar story for how ALSA came to exist, really. Linux folks looked at OSS and said "this blows, let's replace it" and made ALSA. The FreeBSD folks looked at OSS and said "this blows, let's fix it". And did. And they're still on that while Linux is headed into its third major audio shake-up in the same time span (OSS -> ALSA -> PulseAudio -> PipeWire).

alushta 4y ago

dvngnt_ 4y ago

windows still has the audio mixer to beat

steve1977 4y ago
Which is why every professional audio tool uses ASIO and every audiophile player is going to great lengths to avoid the audio mixer and uses things like kernel streaming.

chris222 4y ago

Does MacOS even have OS level independent volume control for each app yet?

brookst 4y ago
Sort of? The kernel supports this and has forever, but the OS doesn’t ship with an app that exposes the capability. It’s super annoying. There are a number of third party apps, some free, some paid.
larrik 4y ago
Not that I've found!
the_other 4y ago
Why should the OS solve app problems?
- dijit 4y ago
  Yeah. Why do we need `open()` anyway? (this is sarcasm, the OS exists only to solve app problems).
yamtaddle 4y ago
This was what everyone said was the reason for wrecking Linux with PulseAudio, all those years ago. I've still never cared and don't know why I should. What am I missing? I've used systems with that, but never bothered to try using it because... why would I? Every media player has a volume control, YouTube has a volume control, every game has a volume control (usually multiple, for different types of sound), and 99% of the time I just want everything at about the same level anyway. The last thing I want to do is have another place a given program could have its volume set or muted or whatever, so then I have another place to look when it's not doing what I want. One per-program (built in to the programs) and one global is quite enough.
- error503 4y ago
  For me it wasn't so much the per-app/stream mixer but per-stream dynamic routing that was the important feature of Pulse (though I've moved on to PW now). I'm not too sure how this is handled on other platforms, but pre-PA the in-app volume control would often modify the global mixer, rather than implement an in-app mixer/attenuator, which is definitely not what you usually want. In most Linux apps these days, those controls manipulate and are synchronized with the PA mixer, so there's still only one actual mixer, they are the same control. I assume that other OSes also do per-stream mixing in a similar manner, and just choose not to expose the mixer for whatever reason. As much as people complain about PulseAudio it's always worked well for me, and from what I've seen of Windows and macOS alternatives, it's more featureful and usable out of the box.