I am using Audacity 2.0.5+svn20131103+r8090-0~r26~ubuntu13.10.1 amd64 Ubuntu 13.10 on real hardwaer. I install this version from deb http://ppa.launchpad.net/audacity-team/daily/ubuntu repository. I have installed pulseaudio 1:4.0-0ubuntu6 from the Ubuntu repository. My sound card is E-MU 0204.
Audacity is able to record from other applications through pulseaudio and record through a mic, but when I try to play sound from files using pulseaudio as the playback device (set to ALSA default), application recordings, mic recordings, Audacity plays the sound back too very fast.
When I select playback device as integrated Intel souncard - playback is normal for everything I play. But my USB sound card isn’t present in playback devices list.
Other applications, like Deadbeef or Rhythmbox play through pulseaudio normally.
I try Audacity from 2.0.3 (ubuntu), but the problem remains on all versions.
If you import a “known to be good” audio file into Audacity and play it - does it play at the correct speed?
If you record something in Audacity and then export as a WAV file, does that WAV file play correctly in Deadbeef or Rhythmbox?
Try selecting the “hw:” option that corresponds to the EMU card in the playback (output) section of the device toolbar.
You can also do the same for the recording (input) section.
The “hw:” options allow Audacity to communicate directly with the device, bypassing PulseAudio. Bypassing PulseAudio means that you will not be able to use features that are provided by PulseAudio, but for ordinary recording and playback it is usually more reliable and stable to access the device directly.
Imported “known to be good” audio file (mp3) played in Audiocity abnormally. (pulse selected as playback device)
Recorded in Audiocity and exported in WAV file played in Deadbeef and Rhytmbox correctly. (pulse:Front Mic:0 selected as recorded device)
I can select EMU 0204 hw: while I didn’t use the sound device, and in this case imported and recorded file played normally. But if I use the sound device, EMU 0204 hw: vanishes from the list of available devices before reboot OS.
When you play in Audacity with Pulse or Default selected as the playback device in the device toolbar, how much “too fast” does it play? Just a bit too fast? Double speed? Extremely fast?
Is the pitch also too high?
If so, how much too high?
From the Help menu, select “Audio Device Info”. Wait a few moments for the list to appear, then copy and paste the device information into your reply.
I was not expecting it to be like that. Thanks for the video, that illustrates the problem perfectly.
Unfortunately I have no idea what is causing it - I’ve never seen anything like that before.
The PPA build that you have has been tested and is not at fault. You should get the same results when building audacity from source with the same configure flags (preferring system libraries over local libraries). If you have non-standard system libraries (libraries that you have manually updated or modified) then the problem could be an issue in one of those.
We think that it is unlikely that the problem lies in or between ALSA and the hardware because we would expect that if that were the case then you would also have problems playing back from DeadBeef and RhythmBox.
What that leaves is the stuff between Audacity and ALSA.
The setup is: Audacity → Portaudio → alsa-pulseaudio bridge → pulseaudio → ALSA → hardware.
Personally I think that the most likely place is the “alsa-pulseaudio bridge” because the following appear to work correctly:
Audacity → Portaudio → ALSA → hardware.
DeadBeef → pulseaudio → ALSA → hardware.
though it is also possible that it lies in:
Portaudio → alsa-pulseaudio bridge
Unfortunately if the problem is somewhere in “Portaudio → alsa-pulseaudio bridge → pulseaudio”, it’s not something that we can fix because it is not our code. It would also be tricky for the guys at Portaudio, ALSA or PulseAudio to fix it either because it seems to be specific to the requirements of the E-MU 0204 and possibly also specific to 64 bit architecture.
I’m trying to think of some sort of workaround that will not be too inconvenient for you.
One possibility would be to try running Audacity with “Jack Audio System”.
“Jack” (also known as “jackd”) is a high performance sound system. It is great for working with audio and multi-media, but it can be difficult to set it up so that it plays nicely with PulseAudio. If you already use Jack, then please try using Audacity with Jack.
If you don’t already use Jack, then I’ll try and think of some other option.
I found the reason of the problem.
At Skype installation I followed the topic recommendation: http://community.skype.com/t5/Skype-для-Linux/Треск/td-p/261858
for noise elimination in Skype.
I added the “load-module module-udev-detect tsched=0” parameter in “/etc/pulse/default.pa”
It caused the wrong reproduction in Audacious
I am sorry for wasted time and thanks for participation.
So is the problem fixed now?
Thanks for getting back to us, but I don’t speak Russian and Google Translate is imperfect.
For my understanding of this problem (in case it occurs for other users) could you describe in more detail how and why you (inadvertently) created the problem, and how you fixed it. In particular, what is “load-module module-udev-detect tsched=0” supposed to do and why does that mess up recording with Audacity?
Now the problem is solved and I continue to use Audacity.
…
One day after the next update, Skype sound began to play with real scratch.
I found decision in skype community - add “tsched=0” parameter to udev initialization string in “/etc/pulse/default.pa” file.
Really I don’t know what means this parameter, and on what it influences in pulseaudio system, but it became a solution of the problem with Skype and led to effect which I showed in video from my desktop.
I found here: PulseAudio - ArchWiki
tsched=0 turns off time based scheduling, but without that your sound card started “free-wheeling” and so playing super-fast.
I’m pretty sick of this Audacity problem at the moment, though I suspect it might be down to Pulseaudio. In the 10-15 years I’ve been using Ubuntu/Xubuntu, I can’t say I’ve seen Pulseaudio working reliably on any machines I’ve used, and It beats me why a fundamental part of an OS doesn’t work ‘out of the box’ and needs in-depth ‘fiddling’!
Anyway, I’ve got the ‘galloping playback’ syndrome - where playback occurs at about 10 times normal speed and if it is paused or stopped, Audacity locks up and has to be killed. Sometimes the playback will randomly switch to normal at some point in the track.
It’s all very frustrating, and I’m now seriously considering searching for a distro that doesn’t use the Pulseaudio sound server (and ‘yes’ I have tried several times reinstalling Pulseaudio and Audacity).
Linux is thousands of different libraries stitched together. Usually it works amazingly well but if you use Linux you have to be prepared to dig around in configuration settings if things don’t work. If you want things to always “just work” you are on the wrong OS.
Uninstalling pulse and Audacity won’t make a scrap of difference but as a starting point you should initialise the audacity.cfg settings file so Audacity runs at default settings. Please see here for how to do that: Audacity Manual .
Have you tried some of the things mentioned in this topic? Have you tried selecting the (hw) devices in Device Toolbar so that you get direct access to the devices, bypassing pulse?
What are you actually playing? If it’s a recording from computer playback you may have sample rate mismatches somewhere. Some audio devices on Linux will only function property at 48000 Hz and do bizarre things at other rates. Pulse should sort sample rate mismatches out in theory but it doesn’t always.
Crossposting a workaround that’s been discussed elsewhere for this problem.
If you run audacity with the environment variable PULSE_LATENCY_MSEC set to any value (for instance, 30 or even 1), then pulse does not exhibit these symptoms.
From a short amount of testing, it looks to me like a value greater than 1 may sometimes be required.
The original posted suggestion with a value of 30 looks very promising to me at the moment.
I’ve been unable to reproduce Audacity bug 276 when using:
env PULSE_LATENCY_MSEC=30 audacity
Rather than Audacity freezing with the bug 276 test case, I get an occasional (and harmless) “underrun”.
