Ironically Pro Tools is still not M1 native.
One cool thing in MacOS that Windows can't do is aggregates of audio devices/interfaces.
One cool thing in MacOS that Windows can't do is aggregates of audio devices/interfaces.
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.
And now we have Pipewire which is not only better, but can also pretend it's Jack for compatibility.
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.
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...
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.
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.
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.
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).
Corporate money and contribution go to: storage, network, scheduler. Anything desktop related doesn't get any love. I bet that PR for EoL drm-kmod from linux still not merged.
It was then that I decided whoever was responsible for it had no software-architectural taste whatsoever. I didn't yet know his name. His work since then hasn't changed my mind.
Yes... it is possible. No, it's not something I ever want to do ever again.
Why do we need `open()` anyway?
(this is sarcasm, the OS exists only to solve app problems).
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.
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.
that does not surprise me at all, unfortunately.
> One cool thing in MacOS that Windows can't do is aggregate of audio devices/interfaces.
it does come at the cost of latency & jitter: fundamental issues that ultimately stem from having two separate audio clocks. and it's not really a specific limitation of windows, which tend to use ASIO for low-latency audio. there's nothing stopping a an aggregate ASIO driver from being written, i just can't imagine it'd be that useful, indeed, i've only ever used the macOS aggregate device a handful of times, mostly only to try it out.
It was a lot of CLI fuckery, not a pleasant experience... and of course pulseaudio can't just remember it, need to be re-applied after every USB reconnect.
Can be done with UDEV but not exactly something random user would know how to do.
Public beta this month, though. https://duc.avid.com/showthread.php?t=422724
Some of us didn't need it, software at the time allowed us to record and mix from and playback to different audio hardware devices simultaneously already. I remember doing that in Windows ME with some audio editing software.