I am running Audacity on a scientific workstation under Ubuntu Linux. It has 18 hardware cores and 36 hyperthreads. The storage device is an internal high performance SSD. The machine has 128GB of high-speed RAM. Audacity will suddenly stop recording and occasionally tell me my storage device is a slow external drive. It is not. Voice activated recording is disabled. Source is an Audio-Technica AT-LP120XBT-USB connected via the USB cord directly to the computer’s built- USB 3.0 port. There are no other applications running. What is causing Audacity to stop recording and how do I fix it?
Audacity is only using one of them …
Let's talk about the Audacity rewrite: One core isn't the game anymore
In defense of the developers I can see why. I avoid multi-thread programming as well. It increases the debugging necessary by a factor that I would have to call logarithmic.
That is not true. As a computer scientist and software developer who has written millions of lines of code, most of it for mission critical applications, I can say with confidence that the advancements in parallel and concurrent programming in the last 20 years are remarkable and enabling. And the processing power of available machines has increased in that time far more by providing more cores than by providing faster clock speeds. Regardless, each of my cores is very fast. The machine was built for numerical analysis, where core speed is at a premium. And the problem I am experiencing does not appear to be CPU driven. When I run Audacity in record mode with the performance monitor on (for diagnostic purposes), all cores are under 5% utilization with no transient peaks. I don’t know the Audacity design, but this strongly suggests that the problem I am seeing is not CPU driven.
Did you even read the answer you were given? Based on the last sentence I guess not.
You know what? Never mind. Someone who says they have written millions of lines of code is full of hyperbole and can’t be taken seriously.
You haven’t seen my resume. I was a Fellow in Lockheed Martin’s organization (top of the tech ladder) for many years. In large engineering organizations, Fellows are the equivalent of endowed chairs in academia (engineering organizations handle different kinds of problems than universities so they set up parallel, but differently focused organizations so that they can attract the best people to solve them). I ran the Advanced Technology team at Lockheed IS&GS. Our job was to solve problems other organizations thought were too hard but which were critical to the national security. And yes, I wrote code with the group every day. Before that I was a Senior Engineer at BBN (the guys who built the Internet in the 60s and 70s). For a while I shared an office with Ray Tomlinson (the guy who invented email). Almost all of our work was on DARPA programs. So my code protects you. You’re welcome. Before that, I earned advanced degrees in Mathematics and Theoretical Computer Science. So my credentials are pretty good and it’s probably unwise to dismiss them.
Much of my work deals with multicore processing. And indeed, the last 20 years have seen great advances. Consider, for instance, the application of Category Theory and Universal Algebra (Monads, Monoids, Functors and the like) to the understanding of problem decomposition. These methods allow us to prove the correctness of concurrent code under all possible scheduling scenarios. Also consider the development of ‘fibers’ for extremely fine-grained efficient concurrency, where you may have millions of concurrent ‘fibers’ attacking complex problems, for instance in sensor data processing, which is basically what Audacity does. Etc. In short, it is you who can’t be taken seriously. For instance, you assert that there is a great “logarithmic” difficulty in refactoring the Audacity code to run on multiple threads. I don’t think the words mean what you think they mean. A “logarithmic” order of difficulty basically means there’s no problem. “Logarithmic” is the opposite of “exponential”. Logarithmic-order algorithms are unicorns. When we find them, we publish and thank our research teams. So you might just take a step back.
Moreover, it appears that you did not read my last sentence. The problem I am experiencing with Audacity does not appear to be CPU driven. None of the cores appear stressed and there doesn’t appear to be a lot of context switching going on. If I were to hazard a guess there is a basic bug in Audacity. I suspect it enters a (handleable) condition that isn’t handled by the code and so it drops to some default behavior that ends the recording process. That’s my educated guess. I do not believe it is hardware related. There is no indication of a hardware issue in other work, which includes some very large computations with Mathematica (in my retirement I have been exploring patterns in the first 20 trillion or so Collatz sequences; some of these computations have pegged all 36 hyperthreads for weeks at a time, with no hardware faults).
You are welcome to dismiss my educated guess about the cause of my experience with Audacity “randomly” exiting record mode under Ubuntu 22.04. You are even welcome to dismiss the issue as a whole. That’s your choice. But you are not welcome to dismiss my experience with computation and software issues. That’s personal, and makes you appear “logarithmically” ignorant.
Audacity’s free competitor OCENaudio has multi-core support, and is available in Linux flavour.
If the problem persists with OCENaudio then it’s not Audacity specific.
I’ll try that. That’s a simple enough test.