I agree that building a debug version of Audacity seems to be the only viable way of investigating this further.
If not, I suspect KXStudio as a possible cause of the problem. Another user on Ubuntu 16.04 found the Audacity 2.1.2 repository version stopped launching immediately after installing KXStudio: https://forum.audacityteam.org/t/audacity-suddenly-wont-open/43023/1 However that issue is not identical because there was some terminal output from Audacity indicating a problem.
Does your other machine have an identical KXStudio setup?
Yes, my other machine which can run audacity also has kxstudio installed through the same package.
I very rarely install software from source, but I do programming in my free time and thus am familiar with the common processes.
After about 5-ish attempts and guessing based on the errors what packages to install, I successfully built and installed audacity from source and it opened successfully, but when I try to use jack as the input or output device, audacity appears in claudia (kxstudio’s jack patchbay and ladish session manager) for a fraction of a second then disappears. This is a far less troublesome issue since I can use a loopback alsa device as a bridge, but still not quite where I’d like.
Since installing from source worked and installing from package did not, would you recommend I contact the package maintainers?
Yes I think it’s worth filing a bug report with them. If yours is the only report of this issue then they will probably ignore it, but if others have the same problem they will hopefully try to fix it.
I’m not sure exactly what you are seeing, but that may be normal. Unlike other Jack aware applications, Audacity does not keep its ports open. It opens input / output ports when needed, then closes them. For example, when you press the Play button, Audacity opens new ports, establishes a connection to the host system, then starts an output stream. When you press Stop, the stream is stopped and the ports are closed.
Yes I know this is awkward and non-standard. The reason for it is historical, is also probably the cause of the common crash problem when using PulseAudio, and is waiting for someone with the time, inclination and necessary skills to fix it.
This is indeed what was happening. it seems audacity also has the common and unfortunate issue that many programs with portaudio have: the ports are different each time the jack client is created, meaning that ladi becomes useless and connections must be remade every time. For now, using the alsa loopback devices will be easier.
Unfortunately that will not work for me since I have to keep self-connection disabled to make many programs better behaved. It is also rarely the case that I want programs to connect directly to the hardware inputs.
Yes I know this is awkward and non-standard. The reason for it is historical, is also probably the cause of the common crash problem when using PulseAudio, and is waiting for someone with the time, inclination and necessary skills to fix it.
I’ve been thinking of learning the audacity codebase in the near future. While this doesn’t sound like a very “beginner” problem, I’ll keep it in mind.
When using Jack, the “device” options in the “device toolbar” are not restricted to hardware devices. On that page you can see an example of setting Audacity to connect to Hydrogen drum machine.
That’s right :sigh: and it was a pain before the device toolbar worked properly for connecting to software. There’s a (ugly) workaround which is probably documented on this forum somewhere (if you can be bothered to search for it). The workaround is based on the fact that although each new connection has a unique port number, the port name always follows the same pattern, and “left / right” have “odd / even” numbers (or “even / odd”, I don’t recall which way round), so the ports can be selected using a regex.
That’s odd. I don’t see carla, a plugin host I had running, in the drop down, but I do see hydrogen. Regardless, since I need to keep self-connections disabled to keep my sanity, this isn’t very relevant.
The workaround is based on the fact that although each new connection has a unique port number, the port name always follows the same pattern, and “left / right” have “odd / even” numbers (or “even / odd”, I don’t recall which way round), so the ports can be selected using a > regex> .
I’m not sure where I’m supposed to type those regexes (what is the plural of regex?), but using the alsa loopback devices will likely be easier to manage.
I think that failure to generate the file might be a red herring.
I’ve had Audacity crash upon startup since 17.10 + KXStudio, with similar symptoms and it persisted over upgrades, reinstalls, everything.
Now I’m on 18.04 and had a same problem. I did a fresh install of 18.04 + KXstudio on my desktop box (which was previously on CentOS) and Audacity worked fine there.
I did work just fine on my desktop finally I did a build with debug symbols included, and it turns out the F****r segfaults upon loading a lv2 plugin /usr/lib/lv2/naspro-dssi.lv2/dssi.so
Once I’d nuked that package, Audacity now starts up just fine.
So something seems to not be quite robust with the way the LV2 plugins are handled - many DAWs, I think load the plugins in a separate process just to keep a crashing plugin from bringing the whole system down. The error messages, or later the crash dump dialog did nothing to point the user to the source of the problem.