3 ms·

I've given up on Audacity because it hasn't kept up technically with how a typical home studio Linux system does audio, and looking at the change log it seems l

I've given up on Audacity because it hasn't kept up technically with how a typical home studio Linux system does audio, and looking at the change log it seems like they haven't addressed any of the problems I have with it in version 4. You'd think, well, it supports JACK, so you're gold on both JACK and Pipewire, but they only do this in an extremely annoying way. It doesn't create a persistent JACK client. Only when you start playback or recording does it temporarily create a JACK client which disappears when playback or recording stops taking any connections you've made to it with it. The temporary JACK client then must autoconnect to a sink or source, for whatever reason that is neither a limitation of PW nor JACK. So you'll undo this jank with an automatic connection manager, right? You'll configure it to immediately disconnect from whatever Audacity decided to connect to and automatically connect it to the source you want to record. Well, they've given the short-lived JACK client the brilliant and informative name "PortAudio", which is of course shared by other applications using portaudio. Even more brilliantly, the I/O ports are given new names on each new client! Some while ago I started Audacity up (having forgotten that it's broken) and got invited to a user survey. There was no concern at all in the survey about the thing that Audacity fundamentally does. Do I want it to be a DAW? Do I want to be able to buy plugins within it? Do I want AI features? Merely being asked these questions while their broken JACK implementation persists pissed me off. I want it to record and play back audio first of all. Audacity 4 looks like it's in the bizarre situation where it kind of looks like a well-designed DAW but behaves like it doesn't care about audio.

TehCorwiz 1mo ago
If you watch the admittedly long video from Tantacrul about what it took to get from 3.0 to 4.0 he talks about that. They had a lot of tech debt that made it impossible to update the audio engine. He talked about the new engine being the roadmap for 4.1.
- boomlinde 1mo ago
  I saw the Tantacrul video back when it was released. I think that's when I went ahead and bought myself a personal Reaper license. My thought then was: wtf are their priorities like if they'll focus on a complete overhaul of the admittedly basic but functional interface over broken recording and playback of audio?
  - TehCorwiz 1mo ago
    There were a bunch of minor versions between 3.0 and 4.0 made up of fundamental refactor work to establish separation of concerns. As I understand it from the call graphs he shared, the problem was that the UI was reaching deep into the audio code directly instead of using a clear API boundary to separate concerns and route commands and change state. So fundamentally while the UI worked, it also was deeply entwined with the audio engine and changing any of the audio back-end basically broke things downstream in unexpected places and couldn't be swapped without deep UI work anyway. So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? Let me repeat that to be clearer: The UI had to be changed internally in fundamental ways to do any work on the audio back-end and they chose to also uplift the design and UX while making it easier to replace the audio engine in a future commit.
    - boomlinde 1mo ago
      > So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? So, if you're going to have to rewrite your back-end to disentangle it from your UI layer anyway why not also bring it up to speed?
      - Sammi 1mo ago
        Because they have 10 people working on it and they can't boil the ocean with that kinds of resources. If you try to do all the things at once, then you get nothing actually to the finish line. You'll be getting what you want in the next point release.
        boomlinde 1mo ago
        So, as I said, a matter of priorities.
      - TehCorwiz 1mo ago
        I don't think you understand the problem they were facing. If they rewrite the backend it would also REQUIRE rewriting the frontend because of how entangled they were. Whereas rewriting the frontend did not require changing the backend as dramatically. So their choices were: 1. Rewrite the whole thing, all at once, ship nothing for a long time. 2. Rewrite the frontend, ship changes incrementally, then move onto the backend once it's been excised from the tangled mess.
bityard 1mo ago
Wow. I ran into a subset of a few weeks back when all I was trying to do was record from a specific microphone connected to my laptop. I thought I just didn't know what I was doing! I gave up after 20 minutes of fiddling and used something else that saw the microphone immediately.

TehCorwiz 1mo ago

If you watch the admittedly long video from Tantacrul about what it took to get from 3.0 to 4.0 he talks about that. They had a lot of tech debt that made it impossible to update the audio engine. He talked about the new engine being the roadmap for 4.1.

boomlinde 1mo ago
I saw the Tantacrul video back when it was released. I think that's when I went ahead and bought myself a personal Reaper license. My thought then was: wtf are their priorities like if they'll focus on a complete overhaul of the admittedly basic but functional interface over broken recording and playback of audio?
- TehCorwiz 1mo ago
  There were a bunch of minor versions between 3.0 and 4.0 made up of fundamental refactor work to establish separation of concerns. As I understand it from the call graphs he shared, the problem was that the UI was reaching deep into the audio code directly instead of using a clear API boundary to separate concerns and route commands and change state. So fundamentally while the UI worked, it also was deeply entwined with the audio engine and changing any of the audio back-end basically broke things downstream in unexpected places and couldn't be swapped without deep UI work anyway. So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? Let me repeat that to be clearer: The UI had to be changed internally in fundamental ways to do any work on the audio back-end and they chose to also uplift the design and UX while making it easier to replace the audio engine in a future commit.
  - boomlinde 1mo ago
    > So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? So, if you're going to have to rewrite your back-end to disentangle it from your UI layer anyway why not also bring it up to speed?
    - Sammi 1mo ago
      Because they have 10 people working on it and they can't boil the ocean with that kinds of resources. If you try to do all the things at once, then you get nothing actually to the finish line. You'll be getting what you want in the next point release.
      - boomlinde 1mo ago
        So, as I said, a matter of priorities.
    - TehCorwiz 1mo ago
      I don't think you understand the problem they were facing. If they rewrite the backend it would also REQUIRE rewriting the frontend because of how entangled they were. Whereas rewriting the frontend did not require changing the backend as dramatically. So their choices were: 1. Rewrite the whole thing, all at once, ship nothing for a long time. 2. Rewrite the frontend, ship changes incrementally, then move onto the backend once it's been excised from the tangled mess.

bityard 1mo ago

Wow. I ran into a subset of a few weeks back when all I was trying to do was record from a specific microphone connected to my laptop. I thought I just didn't know what I was doing! I gave up after 20 minutes of fiddling and used something else that saw the microphone immediately.