Bugzilla – Bug 276
Linux: PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams
Last modified: 2021-09-25 10:44:37 UTC
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).
Promoted to P2 given the number of complaints this receives.
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.
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.
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).
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
(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.
(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.
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).
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.
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.
Updated workaround
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?
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
(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.
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.
See also: https://github.com/audacity/audacity/issues/711
