I am having a problem with Audacity 2.0.4 on OpenSuse 13.1. If I highlight a small section on a track and play it, no sound is generated. I thought that this latency may have had something to do with PulseAudio, but the same thing happens when bypassing Pulse. Is there a way to fix this short of using JACK? Since Suse didn’t have Audacity 2.0.5 in any repo, I tried compiling it myself but got nothing but errors and gave up after unsuccessfully trying to get it to work. The ALSA latency I’m describing is identical to when I select ‘WASAPI’ on Audacity running on a Windows machine.
Also, when opening the edit > preferences menu, then making a change and clicking okay, it blanks out the rest of the menu bars until closing and restarting the program.
What is your “Audio to buffer” setting in Audacity’s “Recording Preferences”? This also affects playback. You cannot play 100 ms selections with a buffer of 1000 ms for example.
Thanks for the info; that has fixed my problem. I lowered the “Audio to buffer” down to 5ms, and changed the output to dmix in the drop-down menu on the Mixer Toolbar. If both of these options are not set, e.g., lowering the latency but not routing through dmix or vice versa, the latency is too high to do any serious audio editing. One suggestion would be for the next version of Audacity to signify to the user that the “Audio to buffer” option also applies to playback. It will be interesting to see what comes of PulseAudio and the way forward for sound on Linux.
Doesn’t the (hw) device also have low enough latency?
How short are the selections you are trying to play?
By the way it’s Device Toolbar that has the output and input selectors.
If users experience a problem that requires to change this setting, it is almost always a recording problem (at least on our main user platform which is Windows).
The Manual for the next release of Audacity will make very clear that the “Audio to buffer” setting also affects playback.
You don’t say what playback device you are using, but if it’s an external card it may have its own buffer setting.
I think dmix is generally regarded as “old” and with inferior mixing algorithms compared to pulse.
Yes, but PulseAudio adds latency to the Linux sound system, and since Audacity by default routes to the default device which on a distro that uses PulseAudio will be the default, it introduces issues beyond what I’ve described. Crashing and scratchy playback are two other ones that I’ve experienced. Since by default Audacity routes through Pulse (on a distro which uses Pulse), you can see a playback stream pop up when you start and stop the audio. So, you can imagine how that introduces more latency as it takes the computer time to process the stream and get it to your speakers or headphones, not to mention that PulseAudio is also one more layer on top of ALSA. It does not make for a good sound system to do any type of audio editing with. It works fine for playing music or general day-to-day computer audio needs.
Very small, e.g., zooming far in and taking out a pop or click. Interestingly, on the same exact hardware, the default “Audio to buffer” setting of 100ms in the Windows version of Audacity (2.0.4 & 2.0.5) using MME or DirectSound doesn’t introduce the same latency problems I’ve had on a Linux box, i.e., setting the sound output to dmix instead of Pulse, but not lowering the “Audio to buffer” setting. Like I said, only lowering the latency and switching to dmix allowed me to get the same kind of performance I did with the Windows version. Also, the dmix option in the drop-down menu disappears at times, and restarting Audacity is required. I’ll try to get version 2.0.5 to compile on my machine and see if there’s any difference.
I’m using on-board audio, a Realtek ALC892 chip – the same audio codec found in devices used in world renown mastering studios, having been used for some of the most impressive recordings. It’s good enough for the project I am doing, at the moment.
Yes, but if Pulse was the only option for Audacity on Linux, it’d be a real nightmare to use.
I’ve been using Audacity with Pulse ever since Pulse became the default on Ubuntu (though I no longer use Ubuntu) and I’ve not found latency or scratchy playback to be problems. Yes it does add a bit of extra latency (about 70 ms here) but adjusting the latency correction pulls it back to be synchronised.
The shortest period of audio that will reliably play with my current settings (cheap laptop, Intel ALC268):
ALSA: 80 ms
ALSA + dmix: 1 ms
Pulse: 80 ms
Jack: 1 ms
Latency:
ALSA: 94 ms +/- 1 ms
ALSA + dmix: 160 +/- 10 ms
Pulse: 168 +/- 1 ms
Jack: 23.2 ms
The only significant problem that I have with Pulse is occasional freezes, generally when switching rapidly between Play and Stop.
I don’t find ALSA + dmix to be usable overdub recording due to the wide variation in latency.
I find
straight ALSA: acceptable for overdub recording provided that no other audio applications are running.
Pulse: acceptable for overdub recording provided that playback does not freeze.
The (hw) device doesn’t use pulse - it should use the hardware directly. (hw) will be slow starting playback or recording because as I understand it, choosing the (hw) device will temporarily suspend pulse for that stream.
I’m not sure what you mean by “ALSA”. There is no “ALSA” device on Ubuntu in Device Toolbar. Do you mean the (hw) device or don’t you see that on Debian?
With the (hw) device on Ubuntu (100 ms buffer in Audacity) I get similar results to you for “ALSA”, but if we are talking about “hearing” a sound, I can’t hear shorter than 30 ms with ALSA and dmix at that buffer setting. Pulse isn’t responsible for the “poor” (hw) result because the result is the same if I turn pulse off in pavucontrol configuration.
I think Linux audio’s habit of chopping off the end of audio is relevant too. Generate a DTMF tone of 1 second. Even at buffer of 30ms using dmix I can’t actually hear absolutely all of it unless I add silence to the end. Same result in VLC but I have not investigated its settings. No issue with chopped off audio on Windows.