Hello everyone,
I am running Audacity v2.3.2 on Manjaro (an Arch derivative), the distribution’s release (though installing the git 2.3.3 version from AUR doesn’t help).
Please bear with me as this is somewhat difficult to describe and I may get terms wrong. For many months now I have had this issue but only recently discovered the cause: when I open Audacity, exactly the moment it becomes ready for use,
You may have tapped the SUBMIT key at the wrong time there. Respond to this posting and continue your question. Don’t get into the habit of going back and patching old work. Those are impossible to follow.
Koz
I did, sorry. I wrote a whole new post which I have submitted before receiving the notification as I didn’t expect such a fast mod response. I will sit back for a while until I’m told whether to post the question again as a reply (I saved a copy) or if this whole thread can be deleted and we use the new one, to prevent back-and-forth.
I’ll erase the other one. Pick it up right here.
Koz
OK, let’s try this again:
Hello everyone,
I am running Audacity v2.3.2 on Manjaro (an Arch derivative), the distribution’s version (though installing the git 2.3.3 version from the AUR doesn’t help). I am using pulseaudio as the audio system.
Please bear with me as this is difficult to describe and I may get some terms wrong. When I open Audacity, the moment it becomes usable, the input on my analog 3.5mm jack microphone seems as though it “lags” and becomes utterly useless, computer-wide. Looking at the “VU meter” for the microphone input on the Input Devices tab of PulseAudio Volume Control, where once it immediately reacted to any noise I made it now is very choppy, updating perhaps once a second. The meters of all other devices such as analog output or its monitor remain unaffected. When attempting to record audio, the time indicator and recording level bar lag too. Recording for around ten seconds gives a quarter second of recording which sounds like a buzz. When I spoke with people through VoIP (Mumble) back before I realized this was taking place, the only sounds that came through as described to me were intermittent, split-second chirps/squeaks.
Everything I have tried beyond rebooting my computer does not resolve the issue. Closing and restarting Audacity, unplugging/replugging the microphone (pulseaudio still thinks it is plugged in), killing/restarting pulseaudio and even killing X entirely and completely logging out of Linux still sees the issue persist.
I don’t know if this is Audacity doing something wrong to the system or the system responding badly to Audacity, but this is the only software I have found that causes this issue, so I figured it best to start here. Thanks.
I’m in Los Angeles and I just watched the Warm California Sun® sink slowly in the west. Linux help is likely to come from England, so backtime as appropriate.
Koz
One way or another, they are not getting along and playing nicely are they.
How much do you know about how PulseAudio fits into the Linux sound system?
When Audacity starts up, it scans the computer’s sound system to see what devices are available, and how many channels / what sample rates they support. If the recording / playback devices that were used last time are present, Audacity will attempt to use them, otherwise it falls back to the system default.
What audio are you attempting to record?
This may be a three way fight. VoIP applications are pretty demanding on the sound system. I presume that you normally have Mumble running in the background?
Don’t use AUR packages for Audacity.
Audacity 2.3.3 is the alpha version and, depending on what development work is occurring at the time, may not work correctly.
The difficult part of this problem is likely to be working out what the problem is.
Enough to get by, but not enough to solve this problem alone it seems haha. Yeah, that behaviour makes sense.
Myself speaking/making noise into my analog microphone, which is usually as clear as day.
No, I only have Mumble on when we’re hanging out online for the night. The only applications always open which presumably may “use” audio resources all the time are timidity++ for MIDI and mpd for music, neither of which touch audio input to my knowledge. I ended their processes and tried again in case. No luck.
OK, I had already gone back to Manjaro’s v2.3.2 anyway.
Yeah. Again, as soon as Audacity has been run once the input is hosed until reboot (though running audacity --version in terminal does not cause this issue, it must fully open). I should be more specific now that I’ve done more testing: the entire Input Device called Built-in Audio Analog Stereo is what has the issue as I get a choppy VU meter no matter the Port I choose: Front Microphone (unplugged), Rear Microphone (plugged in), or Line In (unplugged). To me that seems like a software issue. I don’t believe this has anything to do with my hardware, which is powerful and recent, but I will boot into Windows which I luckily put off wiping and try the same thing to be certain. Thanks for the help btw.
I can’t find any way to edit my post or I wouldn’t double-post. v2.3.2 works perfectly fine in Windows, recording just like I would expect, so I would say this is not inherent to the hardware.
One of the main jobs for PulseAudio is to support multiple clients. Consumer level soundcards these days don’t have on-board mixing, so they can only support one client application at a time. PulseAudio acts as that “one client” application, and handles mixing and routing for multiple clients.
The other main job for PulseAudio is handling sample rate conversion. If, for example, an application such as the web browser, plays a file that is at a different sample rate from the sample rate that the sound card is running at, PulseAudio converts the sample rate to match the hardware.
The importance of this is that if an application wants to use an ALSA device directly (without Pulse), it can only do so if no other applications (including Pulse) are using the device. Audacity uses Pulse by default (assuming that is the system default), but is also able to access ALSA devices directly, bypassing Pulse, but only if the device is not in use.
That’s just background info. Back to the issue at hand…
That’s peculiar. It suggests to me that Pulse is running in system mode (rather than per-user).
Take a look in /etc/pulse/daemon.conf and see what setting you have for local-server-type =
No problem - it’s best to just make a new post anyway, otherwise it can make the flow of the discussion hard to follow.
Good. Thanks for confirming.
$ cat /etc/pulse/daemon.conf | grep local-server-type
; local-server-type = user
From my understanding that’s a commented line that tells one the default so I believe it’s per user. In my XFCE application autostart there is a (I believe to be) default item that starts pulseaudio on login, the command being start-pulseaudio-x11. By the way, I don’t use a login manager, I start X with startxfce4.
I think we may be making progress. When I start X, two “/usr/bin/pulseaudio --daemonize-no” processes start, but when I close X and even log out of Linux, one remains when I log back in to Linux. If I run killall pulseaudio (when X is closed), log out and in, there are no pulseaudio processes, so these are both coming from starting X/xfce. I wonder why one does not close on its own.
However, even if I do kill them all and then run startxfce4 again, the VU meter is still choppy…
In case this helps, in Audacity I have: Audio Host - ALSA (the only option), Recording Device - pulse: Rear Mic:0, Recording Channels - 2 (Stereo) Recording Channels, and Playback Device - pulse
I now have the option to edit as well as report. I’m guessing this is an account age/post minimum setting in the forum. I’ll only edit if no one has replied and make the changes clear.
Are you saying that you have two pulseaudio processes running? 
It shouldn’t be possible to start pulseaudio twice. Attempting to start pulseaudio when it is already running should give an error similar to:
[pulseaudio] pid.c: Daemon already running.
[pulseaudio] main.c: pa_pid_file_create() failed.
Hi, sorry for the delay, I’ve been away. It turns out that I misused pgrep and misunderstood htop which made it appear to me as though pulseaudio was running twice. It is in fact only running once at any point.
Hi,
it seems that I have the same issue.
I am also running Manjaro, version 18.0.4, i3 window manager, Linux kernel 4.19.66-1-MANJARO, with Audacity 2.3.2 installed from the default package repositories. I also use pulseaudio.
The symptoms Sargas described in the initial post are the exact same ones that I experience.
The way pulseaudio is started on my system is via systemd in user mode, which should be the default on arch based systems according to the arch wiki.
Some things I noticed:
When I record something, it seems to be a sped up version of what I was saying, because if I play it back via Audacity with Playback Speed 0.08 or so, it sounds almost normal.
Also, recording only worked just after I installed Audacity. Now when I start it, it only “works” for half a second or if I mash the record button and the recorded sound is either still the strange, sped up version or nothing at all.
If I try to export these recordings, it only becomes static.
I tried starting Audacity from the command line, to see if I got any output, I don’t know if it is unusual or might help but I get a whole lot of:
ALSA lib pcm.c:8432:(snd_pcm_recover) underrun occurred
And when I try to record anything:
Expression 'err' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3355
Expression 'ContinuePoll( self, StreamDirection_In, &pollTimeout, &pollCapture )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3881
Expression 'PaAlsaStream_WaitForFrames( stream, &framesAvail, &xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4253
I’ve also cranked up the log level of PA and made a pastebin of journalctl after clicking on the record button in Audacity, if that helps.
If there is anymore I can provide, I’m happy to help and also for any help provided. 
Not at the moment - it just says:
Pastebin.com is under heavy load right now >
Try changing the buffer setting in Audacity. The default is 100 ms.
First try changing by 10 ms at a time smaller (100, 90, 80, 70…) and note any changes in recording (better or worse).
Then try increasing it by 10 ms at a time (100, 110, 120, 130 …) and note any changes in recording.
The buffer setting is shown here: https://manual.audacityteam.org/man/devices_preferences.html
Let us know what happens.
That’s just come through:
Aug 26 23:21:01 R2D2-manjaro pulseaudio[19464]: D: [alsa-sink-USB Audio] module-echo-cancel.c: Sink input update max rewind 0
>
That could be a problem. Try disabling (not loading) module-echo-cancel.Thanks for the swift reply!
Try changing the buffer setting in Audacity.
Didn’t appear to do anything to the recording unfortunately. The only thing I noticed was that the recording meter in Audacity becomes less choppy the more the buffer size tends toward 0.
Try disabling (not loading) module-echo-cancel.
Same here, nothing.
What I did find out is that I had “Software playthrough of input” enabled. After turning it of, I am now able to record continuously again, without it canceling every half second. But the recording is still sped up and messes up the mic till after the next reboot.
Hi, I am also having this issue! The problem is, merely launching Audacity breaks mic audio system-wide. The audio becomes super choppy and high-pitched. If I close Audacity the problem still occurs in other applications. The only way I can fix it is a reboot. Even restarting PulseAudio doesn’t fix it. Seems like portaudio is doing something weird to the ALSA devices when it probes them. Is there a way I can tell portaudio to not do that, and leave my ALSA devices alone?
Arch Linux Rolling Release
Audacity 2.4.1 (but this has been happening for many versions)
Installed through distro packages
This is using the onboard audio for my 3rd Gen Ryzen CPU. Years ago I was on a configuration with a SoundBlaster Audigy 2 ZS, and opening Audacity would cause it to switch my soundcard to the “raw” 24-bit playback format, removing audio interpolation and making everything sound distorted system-wide until reboot. It bothered me so much I had to quit using the soundcard and switch to onboard audio. But it’s affecting my onboard mic, so I’m considering switching away from Audacity, because it breaks my workflow whenever it breaks my audio devices.
Audacity has to scan the sound system on launch, otherwise it has no way of knowing what audio devices are available.
Are you able to play a WAV file with:
aplay name-of-file
If that works, launch Audacity and then exit Audacity, then try the same “aplay” command again. What happens?