Slackware64-current. 5.4.67 kernel. Fairly clean install from about a week ago.

I installed Audacity using the slackbuilds-current SlackBuild file. I also manually installed audacity 2.4.2, without a SlackBuilds, for testing purposes, both do the same thing.

When I load and play back an mp3 file, it plays very fast - one minute of playback passes in about 4 seconds. I can't find any setting that controls this. It does not matter what mp3 I load and playback, all of them do it, including known good mp3 files that played fine with audacity 2.3.2 in Slackware 14.2.

I built the most current version, 2.4.2 (slackbuilds-current has 2.4.1). Same thing.
I ran it under a different user account to make sure there were no user specific settings causing this. Same thing.
I also tried the "Portable Settings", just make sure there really was not any settings hanging around causing problem. Same thing.
I ran the windows version via wine, and it works perfectly.

This did not happen under Slackware 14.2 and audacity 2.3.2.

At this point I'm not quite sure where to look. Suggestions/advice welcome.

And I just now noticed the console flooding with this:

ALSA lib pcm.c:8545snd_pcm_recover) underrun occurred

Literally thousands of these scroll up.

PS Tried 3.0.0 alpha. Same thing.

Have you tried AlienBob's Audacity-2.4.2 package? Works perfectly on my 64 bit -current.
If you encounter problems with his package as well, maybe the reason can be found in your description of your system as a "fairly" clean install, which could mean a lot of things.

Did you change your default pulseaudio settings? in particular, did you change the defaults for 'default-fragments' and 'default-fragment-size-msec' in /etc/pulse/daemon.conf?

1 members found this post helpful.

I'm currently using his package for audacity and the three deps it lists, jack2, ladspa_sdk and vamp-plugin-sdk. Same thing.

"Fairly clean" means I built it a few weeks ago and haven't had time to screw it up, or so I thought...

Yes, in an attempt to fix the problem, though tbh I'm not really sure what settings would be optimal. Did not help.

What is really weird, if I run it as root (I know, never do this), it will work about 80% of the time. It will start out fast, zip through the first 30-60 seconds, and then suddenly sync up and play normally. Successive runs do the same, but it will not sync in the same place, and sometimes won't sync at all.

After reading your question, and reading numerous accounts of people changing these settings to fix problems like this, I decided to tweak them some more. They start out like this:

default-fragments = 4
default-fragment-size-msec = 25

After playing with them a bit, I settled on these settings, and much to my surprise this fixes the problem. I had to reduce both of them, as reducing just one did not work. I am curious as to why it works?

default-fragments = 2
default-fragment-size-msec = 10

1 members found this post helpful.

The changed speed with root access makes me wonder if this is a resampling issue. I'm pretty sure if you specify sampling rate in asound.conf or possibly better /<User>/.asoundrc that locks sampling rate and "discourages" resampling.

There are pulse options that can limit or deny resampling but it's easier for me at least with ALSA.

I've been having similar problems for a long time; playback would start out as very fast garbled noise, and then seemingly at random, it would fix itself and play the rest of the data correctly.

These settings appear to have fixed the problem for me completely, and I'm with Ook in wondering why/how.

My knee-jerk guess is that pulse is involved, so of course inscrutable things will happen. ;^)
But in seriousness, I wonder if there's something about the way audacity's internal data structures get mapped to the audio subsystem it talks to (pulse in our case) that maybe tries to use a shortcut or makes unsafe buffer length assumptions... something that happens to line up and work as intended in almost all cases, but not for Ook and I, for whatever reason.

Audacity knowing where exactly we are within the file even during wrong/fast playback is very curious. It doesn't rule out a PulseAudio bug, especially given our "fix", but I'd love to show this problem to somebody who is familiar with either audacity or pulse's inner workings.

Maybe it has some interaction with jack2 you have as a dependency. I have discover yesterday with Jamulus which is a realtime client-serveur audio for virtual music/concert, that Puseaudio and jackd are doing a sort of war. Previously they couldn't cohabitate at all.

As a remedy which work very well for Jamulus (delay time was reduce from 120ms to 35ms), you should install the Alien Bob pulseaudio-jack package (and reinstall the pulseaudio from current which is now the 14.0 version to be in sync with the Alien Bob package).

Audacity can also recorder a Jamulus session and it works well.

Maybe you have a weird symptom of the same thing.

It works also on an older Slackware current if you recreate the Alien Bob package pulseaudio-jack and the official pulseaudio of the Slackware current with the Slackbuilds they provided.

I have tested on the lastest with the packages and on an older install with recompilation.