From Fedora Project Wiki

This page explains information that should be included when filing bugs related to PulseAudio. Problems involving PulseAudio should be filed against pulseaudio. Cross-distribution PulseAudio bugs can be reported in the upstream bug tracker, but reporting them in Fedora's Bugzilla is standard procedure.

It is important to note that not all sound problems relate to PulseAudio. See the general sound issues bug information page for instructions on determining whether a sound problem involves PulseAudio, and what component to file a report against if it does not.

Hardware information

See this section of the sound bug information page for instructions on generating a file containing detailed information about your sound hardware. You should include this information with any PulseAudio bug report.

General advice

It is helpful to determine whether the problem you are experiencing is being caused by PulseAudio, or by the specific application you are using. Useful facts to know:

  • Do different applications cause the same problem?
  • If the application supports multiple backends, do other backends have the same problem?

The answers may not be conclusive one way or the other (some audio bugs may affect only one particular application, even if they aren't that application's fault), but the results of any testing you do with respect to these questions would be good information to add to your bug report.

Sometimes it will be unclear which code is at fault until an expert diagnoses the problem, so don't worry about reporting against the wrong component. The important thing is to get your bug into the system if it hasn't already been reported.

The output of pulseaudio -vvvvv, run on the command line, is often helpful. To provide this correctly, first stop the PulseAudio service using those commands:

systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service

Now launch pulseaudio -vvvvv from a console, and reproduce your problem. Provide the whole set of messages from the console where you ran pulseaudio.

To start pulseaudio daemon after the debugging session, reboot system or replace stop command with start:

systemctl --user start pulseaudio.socket
systemctl --user start pulseaudio.service

The output of pacmd ls can also provide a snapshot of the audio system's state.

Sound Devices Not Visible in paman

Use the paman tool to visualize the hardware devices that are being actively used by PA. If your audio devices are not shown, or if only the null source and sink are shown, then it's possible that PA is not recognizing your devices on startup. Try running pulseaudio --system and check the startup output to see if it complains about module-hal-detect. If it does, replace the following in /etc/pulse/

Look for:

load-module module-hal-detect
load-module module-detect

and replace with:

load-module module-udev-detect
load-module module-detect

If this fixes the problem, then paman should show your audio devices listed in its menu after the change has been made.

High CPU load

See for helpful information.

Volume levels

Some applications may cause the volume level to drift over time due to rounding errors, or cause abrupt changes in volume level due to failure to synchronize. It is likely the problem is with the application, so you may wish to file a bug there. Be sure to specify that PulseAudio is being used, and what the sound backend preferences for the application are set to (if there is a choice).

It is intentional that the master volume level for PulseAudio be able to go above 100%, to provide digital amplification.

If reporting a problem with PulseAudio volume or balance levels, the output of "amixer -c0" might be helpful.

Playback problems, crackling or skipping

The PulseAudio sound server was rewritten for Fedora 10 to use timer-based audio scheduling instead of the traditional interrupt-driven approach. Timer-based scheduling may expose issues in some ALSA drivers, often resulting in skipping audio.

If you are experiencing playback problems, try the following workaround, which turns off timer-based scheduling.

In /etc/pulse/, replace the line:

load-module module-hal-detect


load-module module-hal-detect tsched=0 


load-module module-udev-detect


load-module module-udev-detect tsched=0 

Please file a bug report, and note whether or not the workaround fixes the problem.


Please see StackTraces for help on getting useful debugging information in the event of a crash.

More PulseAudio-specific advice is also given at: