6 ms·

Ironically Pro Tools is still not M1 native. One cool thing in MacOS that Windows can't do is aggregates of audio devices/interfaces.

lukeh 4y ago
Public beta coming soon. https://www.pro-tools-expert.com/production-expert-1/apple-silicon-native-pro-tools-public-beta-announced https://www.pro-tools-expert.com/production-expert-1/apple-s...
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.
- 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.
foxhill 4y ago
> Ironically Pro Tools is still not M1 native. 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.
- ilyt 4y ago
  I used it in Linux, but that's because it detected 2-in/4-out audio interface as just three stereo pairs and I needed to split those inputs off to mono. 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.
- steve1977 4y ago
  The one time I've actually used an aggregate device, I synced the clock of one device to the other. It worked fine as far as I remember (it's been a couple of years).
  - 72deluxe 4y ago
    Mine didn't in practice. I think one was a FireWire audio interface and the other USB. Never could get it to work properly.
lightedman 4y ago
"One cool thing in MacOS that Windows can't do is aggregates of audio devices/interfaces." 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.
CharlesW 4y ago
> Ironically Pro Tools is still not M1 native. Public beta this month, though. https://duc.avid.com/showthread.php?t=422724 https://duc.avid.com/showthread.php?t=422724

lukeh 4y ago

Public beta coming soon. https://www.pro-tools-expert.com/production-expert-1/apple-silicon-native-pro-tools-public-beta-announced https://www.pro-tools-expert.com/production-expert-1/apple-s...

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

foxhill 4y ago

> Ironically Pro Tools is still not M1 native. 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.

ilyt 4y ago
I used it in Linux, but that's because it detected 2-in/4-out audio interface as just three stereo pairs and I needed to split those inputs off to mono. 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.
steve1977 4y ago
The one time I've actually used an aggregate device, I synced the clock of one device to the other. It worked fine as far as I remember (it's been a couple of years).
- 72deluxe 4y ago
  Mine didn't in practice. I think one was a FireWire audio interface and the other USB. Never could get it to work properly.

lightedman 4y ago

"One cool thing in MacOS that Windows can't do is aggregates of audio devices/interfaces." 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.

CharlesW 4y ago

> Ironically Pro Tools is still not M1 native. Public beta this month, though. https://duc.avid.com/showthread.php?t=422724 https://duc.avid.com/showthread.php?t=422724