Audacity plays too fast and crashes

[Mathias Bynke]

I use a Samson «Go mic» for recording audio with Audacity. I connect my earphones to the mic and use it for hearing both my own voice live and the computer sound (I have to select it in Ubuntu's sound output settings).

This works fine for a while, and I can record and play back through the mic. Seemingly randomly, however, pressing play or otherwise trying to start playback sometimes makes Audacity skim quickly through the audio, playing garbled sounds which I assume are a fast forward version of my audio. Sometimes, it resumes normal playback before it reaches the end of the file, and everything seems fine. Most often, though, it does not, and pressing the stop button or anything else crashes Audacity. If I restart Audacity and restore the autosaved audio, the problem persists. However, selecting another audio output in Ubuntu's sound settings fixes the problem.

I recently upgraded to Ubuntu 15.10, but this has been a problem since at least 15.04. I now use Audacity 2.0.6-2build1.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: audacity 2.0.6-2build1
ProcVersionSignature: Ubuntu 4.2.0-22.27-generic 4.2.6
Uname: Linux 4.2.0-22-generic i686
NonfreeKernelModules: nvidia
AlsaCards:
 0 [SB ]: HDA-Intel - HDA ATI SB
                       HDA ATI SB at 0xfe024000 irq 16
  1 [GoMic ]: USB-Audio - Samson GoMic
                       Samson Technologies Samson GoMic at usb-0000:00:12.0-2, full speed
ApportVersion: 2.19.1-0ubuntu5
Architecture: i386
CurrentDesktop: Unity
Date: Thu Dec 31 16:11:33 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-11-23 (402 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release i386 (20141022.1)
SourcePackage: audacity
UpgradeStatus: Upgraded to wily on 2015-12-27 (3 days ago)

[Gale (gale)]

If pulse is used as the playback device, repeatedly starting and stopping playback in quick succession may lead to a freeze after which Audacity must be force quit. If the computer is running at high CPU or there are many tracks, a quick hit of Space twice to start and stop, or holding down Play with the mouse, may be enough to cause the freeze.

The same issue can occur if you R and space rapidly and repeatedly to start and stop recordings, or hold down the Record button.

If the device is set to an ALSA/hw choice (so bypassing pulse) these issues do not occur.

Al regards this as most likely a bug in PortAudio's support for libpulse, and/or possibly libasound,

This bug is the cause of bug 133 (moving the transcription slider is not allowed to restart playback on any platform, even though it could be allowed on Windows and Mac).

[Gale (gale)]

Promoted to P2 given the number of complaints this receives.

[James-k-crook (james-k-crook)]

Title changed to emphasise that WDM/KS issues (Bug 651), WASAPI issues (Bug 652) and these PULSE-AUDIO issues are serious P2 problems that live in code 'below' Audacity - they are in portaudio and the host OS sound system.

These are likely to be long standing P2 issues. We may be able to address them by 'workarounds' in our code, i.e. by using portaudio differently.

This particular bug could be eliminated by keeping the sound card open all the time from once it is first open, and instead enabling/disabling playback and recording by switching in and out different audio callbacks. This solution would benefit all sound systems. It eliminates clicks on start/stop, facilitates monitoring when not recording (the sound card is of course open when monitoring), and has the advantage on Linux that ports remain visible and routable via Jack even when they are stopped.

[steve d (stevethefiddle-gmail)]

Just to add that this bug is most easily reproduced by rapidly restarting playback, but does not require rapid and repeated pressing of the spacebar. The bug can (and on my machine frequently does) occur during normal use.

As Pulse is the default sound system for most modern distributions, and Audacity is not usable for important work with Pulse (too unreliable), I think this bug well deserves the P2 priority.

Re. comment 2, keeping the ports open would be a great benefit for Jack users.

[Gale (gale)]

Assuming this isn't on the agenda for fix in 2.1.2, how about adding

  env PULSE_LATENCY_MSEC=30

to the Exec commmand in /src/audacity.desktop.in to reduce the number of complaints we receive?

Of course this depends on the distros accepting that change, and we could argue whether the value should be "30" or something else, but "30" solves the problems about 80% of the time.

The "30" value solves another problem noted in the release notes but not in the bug title (that playback can skip through at many times normal speed).

[steve d (stevethefiddle-gmail)]

This issue does not appear to be completely fixed, I can still get Audacity to freeze if I give this bug a hard work-out, but it seems to be greatly improved in recent builds on my machine and freezes are now rare during normal use.

When starting / stopping the audio stream rapidly it is not uncommon to see:
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

[Gale (gale)]

(In reply to Steve Daulton from comment #5)
What might have partially fixed it? It seems almost as bad as ever on my lethargic Ubuntu 14.04 netbook.

[steve d (stevethefiddle-gmail)]

(In reply to Gale Andrews from comment #6)
I think that some of the changes that Paul made for his "scrubbing" feature may be responsible for the improvement.

The improvement is very noticeable on my machine. Basic operation is now reasonably stable, whereas previously it was unusable without some workarounds such as using a "hw" device. The problem is certainly not "resolved" because I can still easily make Audacity freeze, for example if I loop play a very short section of audio.

[Raymond (superquad-vortex2)]

s. 31 16:05:42 hostname pulseaudio[1728]: [alsa-source-USB Audio] alsa-source.c: ALSA vekket oss for å lese nye data fra enheten, men vi fant ingen data! des. 31 16:05:42 hostname pulseaudio[1728]: [alsa-source-USB Audio] alsa-source.c: Dette er høyst sannsynligvis en programfeil i ALSA-driveren «snd_usb_audio». Vi ber om at du rapporterer feilen til ALSA-utviklerne. des. 31 16:05:42 hostname pulseaudio[1728]: [alsa-source-USB Audio] alsa-source.c: ALSA vekket oss med POLLIN valgt, men en påfølgende snd_pcm_avail() sendte 0 - eller en annen verdi som var lavere enn «min_avail» - i retur. des. 31 16:09:18 hostname pulseaudio[1728]: [alsa-sink-USB Audio] alsa-sink.c: ALSA vekket oss for å skrive nye data til enheten, men vi fant ingen data! des. 31 16:09:18 hostname pulseaudio[1728]: [alsa-sink-USB Audio] alsa-sink.c: Dette er høyst sannsynligvis en programfeil i ALSA-driveren «snd_usb_audio». Vi ber om at du rapporterer feilen til ALSA-utviklerne. des. 31 16:09:18 hostname pulseaudio[1728]: [alsa-sink-USB Audio] alsa-sink.c: ALSA vekket oss med POLLOUT valgt, men en påfølgende snd_pcm_avail() sendte 0 - eller en annen verdi som var lavere enn «min_avail» - i retur. des.

[Mathias Bynke (mabynke)]

This problem has now shown up on another computer without the Samson mic connected. I'm running Ubuntu 15.10. The bug only starts after a good while of use.

Running from the terminal, I get the following error many times a second for as long as the garbled sound plays:
«ALSA lib pcm.c:7905:(snd_pcm_recover) underrun occurred»

[Nicholas K (ubuntu1-m-deactivatedaccount)]

I have this same issue with fast playback and the same error message

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

Ubuntu 15.10
Audacity 2.0.6

[Gale (gale)]

Promoted to P1 so people know the plan. A consensus seems to have emerged to try to fix this for 2.1.3 rather than 2.1.4. I was going to raise to P1 for 2.1.4 anyway because the damage to our reputation from this bug is escalating and the line must be drawn somewhere where we won't let this go on any longer.

The attempted fix will be as James describes in comment 2 to keep the audio ports open while Audacity is open. If successful, this also fixes enh bug 1205 (P3, but so longstanding that it's a candidate for P2).

[James-k-crook (james-k-crook)]

https://github.com/audacity/audacity/commit/05fe6841143e4ee6c5d2d816e28c732289e5849a

is a small step towards this, as function StopIfPaused is now the place to add code that will handle the (small) differences between stop and pause, such as the position of the play head and the transport button state.

[Gale (gale)]

James says the work is not complete to keep monitoring always on, and meantime some improvements for pulseaudio lockups are expected to be in the upcoming PortAudio release.

So James and I agree to demote this back to P2, try a PortAudio upgrade after 2.1.3 release then take it from there.

[Oskar Wallgren (oskar-wallgren13)]

I added upstream bug and edited the bug title to reflect that it isn't related to that specific microphone but a bug in Audacity (or PortAudio...).

From the release notes here: http://wiki.audacityteam.org/wiki/Release_Notes_2.1.2#Miscellaneous_platform-specific_issues

>A playback or recording freeze, recording dropouts or fast playback may occur when using PulseAudio. Freezes may be caused by repeatedly starting and stopping playback or recording in quick succession (or by holding down the Play or Record button). Workarounds: Try launching Audacity from the terminal with the pulse latency set to 30 ms in an environment variable:

env PULSE_LATENCY_MSEC=30 audacity
If you get underruns noted in the terminal, try a higher number in the PULSE_LATENCY_MSEC command. If the problem is unchanged, try a lower number. Alternatively, bypass pulseaudio by setting the playback and recording device to an ALSA (hw) choice in Device Toolbar

[James-k-crook (james-k-crook)]

Updated workaround

[Petersampsonaudacity (petersampsonaudacity)]

Steve wrote by email:

An alternative workaround for bug 276 appears to be to set the output
device to "dmix". I've been testing this for the past couple of days,
and no freezes when using dmix.

The advantage of dmix over "hw:" is that the vast majority of sound
cards do not have hardware mixing, so when the "hw:" device is used,
only one application can use it at a time. On the other hand, dmix is
a plug-in for ALSA that provides mixing, so multiple applications can
use the sound card simultaneously.

The downside of dmix compared to the "hw:" device is that not all
distros install it by default (though I think that most do).

The downside of dmix compared to PulseAudio is that it does not
support recording what is playing on the computer.

PulseAudio would be the best device to use if it were not for bug 276
(and it is the default for most modern Linux desktops).

Do we want to document this somewhere?

[Leland-audacityteam (leland-audacityteam)]

Steve, can I get you to try this again as portaudio has been upgraded. I have not gotten it to freeze, but I do get strange results with pulse.

I have 32-tracks of Chirp and if I have the "pulse" device selected, the first time I Play it sound just fine. But I get a lot of skipping of the playback and tons of these messages on the console:

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

[steve d (stevethefiddle-gmail)]

(In reply to Leland Lucius from comment #13)
Testing today, PulseAudio playback is behaving remarkably well.
I'm able to produce lots of "underrun" errors when scrubbing with a lot of tracks, but no freezes.

[James-k-crook (james-k-crook)]

It sounds in light of comment 14 like the freeze in the title of the bug has gone. We possibly need a new P3 issue for under-runs with Pulse. I regard this bug as no longer a P2, given the updated portaudio.

I propose closing of this bug. In the interim though, before we open a new under-run bug, demoting this bug to P3 since it appears not to happen on modern hardware with updated portaudio.

[steve d (stevethefiddle-gmail)]

See also: https://github.com/audacity/audacity/issues/711