New Feature Request: A "NEVER Change My Device" Setting

Audacity 3 Help Forum GNU/Linux
1

I’m on Linux, and as you probably know modern Linux distros use Pulse Audio, which sucks and makes things hard for Audacity. For instance, if I try to use the default output device in Audacity, I’m guaranteed to have it crash in the middle of my work.

In another thread I learned that Pulse was responsible for this, and that the fix was to stick to a specific “HDA Intel PCH: ALC892 Analog” device for output. As long as I do that, Audacity and Pulse Audio seem to play nice.

However, the problem is that Audacity does everything in its power to go back to the default device. If anything at all on my system does anything with audio, like say I look at a tab in Chrome with a video in it … Audacity uses that as an excuse to say “well, the analog device is in use, guess I’ll go back to default”.

Again, I’m sure this isn’t Audacity’s fault, and that it’s Pulse Audio’s, but what it results in is: A) I do a ton of work B) I close the file C) I use my web browser D) I open the file … and then finally E) I fail to notice that Audacity has gone back to the default device, so I work for awhile then suddenly crash and wind up with missing bits of my file.

I’m not asking you fix Linux audio and the nightmare that is Pulse: who knows if that’s even possible? But if you could just give me some way NOT to have Audacity switch back to data-destroying mode (ie. default audio output), it would save me from soooo many recoveries.

2

Does selecting “Default” as your input device differ from selecting “Pulse”?

I choose “Pulse” for both input and output device and don’t seem to experience the issue you describe.

ATB,
Neil

3

If Pulse is working for you, stick with it. Audacity “should” work with PulseAudio, but it is a known problem that for many (but not all) Linux users, it causes Audacity to freeze. If you’re not getting the freeze problem, consider yourself lucky and enjoy using Audacity.


Glad to hear the workaround works for you.


That’s not quite an accurate characterisation. It would be more accurate to say that if the hw:0 device is not available, then Audacity will fall back on the system default device, which on modern Linux systems is almost always PulseAudio.

I wouldn’t recommend doing so, but it is “possible” to change the system default audio device. If, for example, the default playback device is hw:0, then Audacity will try to use that by default. However, if hw:0 is not available for Audacity, then you would get an error when trying to play from Audacity.

The “correct” solution to the problem, is for Audacity’s PulseAudio problem to be fixed. Unfortunately that’s beyond my programming ability (it’s a difficult problem).

4

I appreciate the response, but … is this not a valid feature request?

If some software had a button which made the app crash and destroy data, even if it had a legit purpose, wouldn’t it be reasonable to ask to hide that button? Similarly here, while I fully understand why Audacity defaults back to the default … is it so crazy for me to ask for a way to have it not do that … when the outcome of doing it is an all-but-guaranteed data loss?

I get that the data issues themselves are outside both mine and Audacity’s control … but the one thing that is, 100%, within Audacity’s control is whether it switches devices.

And while of course it’s naive for me to make assumptions about the software’s architecture … I can’t help but feel this boils down to a boolean setting, and a simple “if” statement which checks that setting, in whatever code switches devices.

“if (new switch setting === false) return”: that’s all I’m begging for here, one line (or maybe one line repeated in a few functions; again I’m not trying to imagine that software changes are ever easy, but this one certainly seems on the easy side).

And if the UI for that setting itself is too much work I’ll happily fill out an .ini file, or pass a command line arg, or do whatever else to tell Audacity I’m a weirdo whose computer explodes easily. But right now I can’t control Pulse Audio, and I can’t control Audacity, and Audacity won’t control itself … and I REALLY hate investing hours in audio files only to have them be destroyed because I looked at a cat video in my browser (which, because it had audio, effectively told Audacity “please, destroy that data”).

P.S. As a side note, a feature that prevents Audacity from destroying open files would be equally awesome. If I open a previously saved Word doc and Word crashes, I don’t lose random characters from my save, it just goes back to the way it was before I opened it … but that’s exactly what happens in Audacity: simply opening a file and never saving it can lead to a playback error which corrupts the file.

That truly seems like the core issue in need of fixing: no data editing app should even have the ability to destroy data until you save … but avoiding the conditions which trigger data loss with a setting and an “if” seems like a much easier fix.

5

So if you set Audacity to use a USB mic, then shut down Audacity and unplug the USB mic, and then restart Audacity, what, in your opinion “should” Audacity do?

6

I’ve been struggling with this issue for over a year, and at this point I’m a little “gun shy”, and afraid to run Audacity with any output except “HDA Intel PCH: AL892 Analog”, because in the past any other setting resulted in Audacity crashing (and losing data). I don’t remember for sure, but I likely tried using “pulse” in the past, and it similarly crashed.

I probably have a unique setup. I have two sound cards already (I guess my graphics card has one built in), and then (on the recommendation of this forum) I bought a third USB sound card specifically to record at the best possible quality. I realize most people don’t have this, and also most people don’t use Linux and Pulse Audio, and so I have a somewhat unique problem.

But even so … data loss is a painful problem to have, so any solution (even a secret undocumented command line arg) that let’s me tell Audacity “please never destroy my data” would be so very much appreciated.

7

I agree that crashes and data loss are to be avoided at any cost.

More recently, I’ve been using a Zoom H5 for my recording medium. I also have a Zoom Q2n which can perform a similar function with lavalier microphones. The only time I record into the computer is with a R0de NT1 and Focusrite Scarlett 2i2 combination.

A particular distribution’s implementation of PulseAudio might be a factor too. I did experience some quirks with it on fedora but my Ubuntu-derived Linux Mint seems to be quite stable. @steve could probably comment on how PulseAudio performs for him on Xubuntu.

ATB,
Neil

8

With PulseAudio on Xubuntu, Audacity occasionally freezes. It’s extremely annoying, but invariably Audacity can automatically recover the project after killing and restarting Audacity.

For serious work with Audacity, I use Jack Audio System, which works flawlessly.

9

More recently, I’ve been using a Zoom H5 for my recording medium. I also have a Zoom Q2n …

It’s also a recommendation of the forum that if you have a lot of trouble recording on the computer, stop recording on the computer. A significant portion of forum help is directed at helping people force their computer to record good quality sound. It’s not simple and it’s not automatic no matter what USB microphone and interface makers want you to think.

Koz

10

To be clear, my issue is with data destruction. My mic doesn’t destroy my data, regardless of whether I unplug and plug it back in, so I have 100% no opinion whatsoever what Audacity does.

Is the only issue that it’s not possible to have a “null” device? Like is the real problem that when a device goes away, the software HAS to pick something?

11

But, whatever it took to get here, I have a GREAT environment now. Everything works, I can record what I want, I can use audacity to normalize the sound, remove noise, and manually remove clicks. I even have handy plug-ins which rename my tracks in numeric order, and which output each track’s time so I can use it to sync up the video.

As evidence, I’ve used Audacity to create an entire eight week college course, and I’m now on week six of a new one. It is absolutely wonderful software which I love using on a daily basis …

… until the software stabs me in the back :wink: No, I’m not serious, just blowing off steam, but data loss feels that way. Audacity is PERFECT for me … right up until I look at a cat video, at which point Audacity decides that it should stop using the device that works, and switch to the one that crashes and destroys data, without as much as a single modal saying so.

(Literally if all Audacity did was pop up a message saying “We’re about to destroy your data” when it switches devices … and of course it would really say something more like “I just changed devices because the old one became unavailable” … that alone would save me from tons of data loss).

And again, none of this would even be an issue if it wasn’t for the fact that simply opening a file in Audacity, and then having it crash, damages that file. If all I lost was my unsaved work (ie. if it could work like Word and similar text/code editors do) this would be a non-issue for me.

12

So why is that not happening on your machine? It seems that in this discussion we are conflating two different problems as one. We’ve talked at length about the potential freeze with PulseAudio, but your real concern is the other problem, that the project is not being recovered. Perhaps we should talk about that and see if we can discover why auto-recovery is failing you.

13

So, let’s say I open a file and work for a bit, and then Audacity crashes because I didn’t realize it was on the wrong audio. When I restart it, the recovery thing will ask if I want to recover, and if I do I’ll likely get back what I recorded.

But what I’m talking about is the fact that, regardless of whether I even do any editing or recording at all, if I just play an audio track, and it crashes Audacity, when I bring it back up I inevitably have some number of lost sectors, or orphaned bits, or something like that. Audacity helpfully gives me the option of preserving them, but as far as I can tell I can’t restore them so that seems meaningless.

It seems like the only practical option, unless I just want to keep being asked forever every time I open the file, is to delete them, and then (unless this is my misunderstanding?) I’ve just lost a bunch of small bits of my file as a result of the crash.

14

Audacity is a bit over-zealous when recovering from a crash. It will often report “orphan” bits, because it looks for all bits of data that might possibly be part of an old project. Very often it will find blocks of data that are not actually used by the project that is being recovered.

What “should” happen in the “normal” situation, is that on exit, Audacity cleans up and deletes all old data blocks that are no longer referenced by the project (mostly “undo” data). If Audacity crashes, or freezes and has to be restarted, Audacity does not get the chance to clean up those unreferenced data files. Rather than just deleting them, Audacity first tells you about them (this may change in future versions of Audacity). In short, a lot of those “warnings” are irrelevant. The difficulty for Audacity is that Audacity can’t tell if an “orphan” data block is important or not - usually not, but Audacity does not know that for certain.

The Audacity developer’s are considering moving to a different format for Audacity projects; one that does not rely on a separate _data folder, so such problems may (eventually) cease to exist.

15

All of that is fascinating, especially the idea of not having those folders (I’ve lost multiple projects because, before I learned better, I moved or renamed an audacity file and didn’t move its folder, but thankfully never anything terribly important).

But yeah, just speaking as a software developer, I think the idea of removing those alerts is a great one. If I as the user can’t do anything about it, then really all you should be saying is “we lost some data”. And if that data is only unsaved work, telling me that I lost important data is similarly unhelpful: I genuinely thought I was adding tiny errors to my files every time Audacity crashed because of it.

So, can I now safely assume that my saved work will never be lost by an Audacity crash? And that if I just ignore the “want to restore your unsaved work?” dialog AND just click “delete my orphaned files” (until hopefully it someday goes away) … all I’ll lose is my unsaved work?

And also, just a question about that: I “lose sectors” even when I have no un-saved work. Like literally A) I open a file, B) I play a track, C) Audacity crashes, D) I restart it and get the orphan message. Are those orphaned bits just from stuff Audacity was doing in-memory that I don’t care about, or is there some chance those were from my saved file?

16

If you receive an error message, always read it carefully. An Audacity project is a complex structure and there are countless ways that a project can be damaged - many of them beyond the control of the developers (for example, a while back we saw a number of Audacity users losing projects due to a version of Norton 360 deleting the project’s data file because it thought they were unimportant clutter).

Always make backups of important work. The “Save Lossless Copy of Project” feature is a good way to save backups.

If you mean that you open a “project” (Audacity “opens” projects and “Imports” files):
I have never seen that happen, and I can’t think of any way that could happen.

If you mean “A) I import an audio file, B) Play it, C) Audacity crashes, D) There are orphan files”
then the orphan files belong to the crashed project, but you have lost nothing because the audio file still exists, and there never was a saved project.

17

If you mean that you open a “project” (Audacity “opens” projects and “Imports” files):
I have never seen that happen, and I can’t think of any way that could happen.

No, I meant “open an Audacity project”, not import anything. I just tried to reproduce it now … and of course, the one and only time I want Audacity to crash … it doesn’t :laughing:

But if you’re unclear about how the crash could happen, it’s that playing the audio on my “default” (pulse) audio device causes it. If you’re unclear about the “orphaned bits” dialog showing up, I’m like 85% certain it did … but to be fair I do my best to avoid such crashes now (the last time I had a serious one with data loss was when I started this thread, and I haven’t had any since), so I can’t say so with certainty.

18

Yes, that’s the part that I can think of no explanation for. If you simply open a project and press play, Audacity doesn’t do anything to change either the .aup file or the audio data.

19

See that’s exactly how I feel Audacity should work (what I mean by “like Word”): opening for read access shouldn’t result in (write-access-requiring) data loss.

However, I swear I’ve had just that happen. I understand my report seems illogical, but unfortunately since I do my best to avoid these errors, all I can offer is that, if I see it happen again I’ll report back with as many details as I can (no matter how hard I try, it seems I’m bound to forget and accidentally reproduce it at some point).

Also I’m unclear about a related case: what if, say, I make a few edits, but don’t save. Can that result in existing data loss, if choose not to recover? I’m even more certain I’ve gotten orphaned bits in that scenario, but it sounds like you’re saying those bits are from my unsaved work, not my existing data?

20

Please do.


“Orphan block files” are usually both harmless and useless, but…
“Missing block files” indicates that audio data that is required by the project can’t be found. In this case, there may be “orphan” block files that are actually the same block files that are “missing”. In practice, it this unlikely to happen, but if it does, then it would “theoretically” be possible to manually put the orphans back where they belong. In practice, you probably won’t be able to get all the pieces in the right places.

In years gone by, automatic recovery was pretty poor, and there were times when automatic recovery would fail, but manual recovery from the “orphan” files was a “possibility” (though the chance of successful manual recovery was not good). These days, automatic recovery has improved to the stage where, if it can be recovered, it is recovered, but if auto-recovery fails, then recovery is probably impossible.

Personally, I’ve not even tried manual recovery for several years. In (thankfully rare) cases where a project can’t be opened correctly, I now give up on it straight away and turn to my backups.