Audacity 2.0.5 no longer plays or saves audio files correctl

Audacity Help Forum GNU/Linux
1

I’ve been using Audacity under Linux for several years to record, convert, and edit audio files (mostly music). On my primary (Lubuntu 14.04.1) workstation, Audacity 2.0.5 is no longer able to correctly play any audio files I’ve read in – MP3, OGG, FLAC, or even its own AUP project files (created on the same workstation). The waveforms look “reasonable” when I load them, but when I play, I get something akin to a record-scratching sound passing through the track at high speed. I can export the unchanged loaded file to another file, but the result, although playable outside Audacity, plays at a lower pitch and slower tempo, as if Audacity read the original incorrectly and saved it that way.

Assuming I somehow messed up config files, I did a complete removal of audacity and audacity-data, then reinstalled. No change.

Anyone have ideas about what might be the problem? Again, some of these files are ones I’d previously edited with Audacity (possibly an older version), and all of them play perfectly well using other programs like Audacious, QuodLibet, SMPlayer, Videos (totem), and VLC. Thank you!

2

Have you tried running audacity like that:

env PULSE_LATENCY_MSEC=1 audacity

? I had similar problems with 2.0.5 and they were fixed by that; it was suggested in some other thread in this forums. (Then I somehow broke my Audacity myself; I will have to open a thread on it.)

3 



env PULSE_LATENCY_MSEC=1 audacity

(or slightly higher value) as suggested by Elwro should help if you are using the pulse or default device for playback and if it’s only a playback problem.

You don’t have a Time Track open, do you? That would cause the export to be made at a different pitch and tempo, but also different length.

If you launch Audacity normally (without env PULSE_LATENCY_MSEC=1 audacity), import one of those files, export a selection, then File > Open… the exported file in a new Audacity window, what speed does it play at, and is the length of the file correct?

And if you repeat those steps but launch Audacity with env PULSE_LATENCY_MSEC=1 audacity, is the playback of the exported file the same?


Gale

4

Thanks, Elwro, Gale! I’ll check these out and report back.

5

Okay, here’s what I found out…

First, the env-variable setting did fix things initially. (I switched back and forth between using it and not, and the effect was consistent.) I dug up a mention that one can apply this to the menu-based start-up of Audacity by modifying the /usr/share/applications/audacity.desktop file and changing Exec=audacity %F to:

Exec=env PULSE_LATENCY_MSEC=1 audacity %F

at least on my Lubuntu 14.04.1 system (YMMV).

I also tried to figure out why the latency change, to see if I could fix the problem at its source. When I’d run (non-tweaked) Audacity from the command line, I got a stream of the following errors upon playing the file:

ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
. . .
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

ArchLinux.org had a discussion ([SOLVED] ‘(snd_pcm_recover) underrun occurred’) that suggested changing shrinking the default-fragment-size-msec setting in /etc/pulse.conf, as (according to their PulseAudio/Configuration page), larger fragments of sound to process can increase latency.

I tried this out, changing default-fragment-size-msec=10 and default-fragments=8 to:

default-fragments=16
default-fragment-size-msec=5

(I doubled default-fragments to provide the same buffered amount and avoid underruns, I hope). After making sure the pulse daemon would start fresh with pulseaudio -k, this seemed to work. Audacity played things normally without the PULSE_LATENCY env setting.

But when I switched it back, Audacity still worked. Huh? I rebooted to make sure PulseAudio came up with its original settings, and Audacity stubbornly refused to break, even without any changes.

So, I’m back to thinking there’s something transient in my environment that can cause Audacity to suffer latency problems. But at least there are two possible fixes:

  1. Set PULSE_LATENCY to 1, either by command-line invocation or with an audacity.desktop setting.
  2. Change the fragment settings in PulseAudio’s daemon.conf.

A third way might be to simply increase the default-fragments, since the problem apparently generated an “underrun” error.

Hope this helps anyone else who might run into this problem. Thanks again to Elwro and Gale, and to the ArchLinux folks, for the tips. (I didn’t get to try Gale’s tests because the problem went away on its own, but I’ll keep them in mind if it returns.)

6

Thanks for posting the more permanent ways to set a lower latency in pulse.

However none of that explains why the exported audio data was apparently at the wrong speed. If you renamed any tracks, that can trigger an unwanted track sample rate change in Audacity on Linux, which “could” be the explanation.

Gale

7

You’re right, Gale. Even worse, a similar problem started happening immediately after I wrote all this! Slght difference, though: I got a “frying” sound (similar to what I heard during bad, high-speed playbacks) while recording. I immediately tried the env approach, but although the recording worked, its playback was consistently pitched low as before, and I got the stream of underrun errors again. I even tried the commonly suggested value:

env PULSE_LATENCY_MSEC=30 audacity

but got the same problems. (RE: one of your ideas above, I didn’t have a Time Track open during any of these attempts. Despite how long I’ve been using Audacity, I haven’t even gotten around to using them yet. :blush: )

So, I implemented the change to /etc/pulse/daemon.conf above. So far, everything is working perfectly. But there’s clearly something going on under the covers of my system that I haven’t figured out yet. I’ve got a lot of audio work to do this week, so I hope I can explore this a bit more.

Jeff Q