Launchpad has imported 11 comments from the remote bug at http://bugzilla.audacityteam.org/show_bug.cgi?id=276.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-02-04T01:35:04+00:00 Gale wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/0 ------------------------------------------------------------------------ On 2015-04-01T17:00:38+00:00 Gale wrote: Promoted to P2 given the number of complaints this receives. Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/1 ------------------------------------------------------------------------ On 2015-04-04T08:11:28+00:00 James-k-crook wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/2 ------------------------------------------------------------------------ On 2015-04-04T13:41:25+00:00 steve d wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/3 ------------------------------------------------------------------------ On 2015-07-18T18:45:20+00:00 Gale wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/4 ------------------------------------------------------------------------ On 2015-09-22T08:03:28+00:00 steve d wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/5 ------------------------------------------------------------------------ On 2015-09-23T03:35:30+00:00 Gale wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/6 ------------------------------------------------------------------------ On 2015-09-23T07:46:48+00:00 steve d wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/7 ------------------------------------------------------------------------ On 2016-07-14T22:20:50+00:00 Gale wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/13 ------------------------------------------------------------------------ On 2016-08-20T18:01:12+00:00 James-k-crook wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/14 ------------------------------------------------------------------------ On 2016-10-05T15:05:34+00:00 Gale wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1530365/comments/15 ** Changed in: audacity Status: Unknown => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1530365 Title: Audacity plays too fast and crashes To manage notifications about this bug go to: https://bugs.launchpad.net/audacity/+bug/1530365/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
