(add link) |
(expand based on email from Lennart) |
||
Line 1: | Line 1: | ||
==Playback problems== | ==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 afflict 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, might be helpful. PulseAudio is normally started by the desktop environment, so you will probably need to kill the existing server with the command "pulseaudio -k". | |||
Cross-distribution PulseAudio bugs can be reported in the [http://pulseaudio.org/wiki/Community#BugsPatchesTranslations upstream bug tracker], but reporting them in Fedora's Bugzilla (at bugzilla.redhat.com) is standard procedure. | |||
==High CPU load== | |||
See http://pulseaudio.org/wiki/HowToDebugCPULoadBugs for helpful information. | |||
==Playback problems or skipping== | |||
The PulseAudio sound server was rewritten for Fedora 10 to use [[Features/GlitchFreeAudio|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. | The PulseAudio sound server was rewritten for Fedora 10 to use [[Features/GlitchFreeAudio|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. | ||
Line 11: | Line 30: | ||
Please file a bug report, and note whether or not the workaround fixes the problem. | Please file a bug report, and note whether or not the workaround fixes the problem. | ||
==Crashes== | |||
Please see [[StackTraces]] for help on getting useful debugging information in the event of a crash. | |||
More PulseAudio-specific advice is also given at: http://pulseaudio.org/wiki/Community#BugsPatchesTranslations |
Revision as of 02:00, 31 July 2009
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 afflict 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, might be helpful. PulseAudio is normally started by the desktop environment, so you will probably need to kill the existing server with the command "pulseaudio -k".
Cross-distribution PulseAudio bugs can be reported in the upstream bug tracker, but reporting them in Fedora's Bugzilla (at bugzilla.redhat.com) is standard procedure.
High CPU load
See http://pulseaudio.org/wiki/HowToDebugCPULoadBugs for helpful information.
Playback problems 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.
Replace the line:
- load-module module-hal-detect
in /etc/pulse/default.pa with:
- load-module module-hal-detect tsched=0
Please file a bug report, and note whether or not the workaround fixes the problem.
Crashes
Please see StackTraces for help on getting useful debugging information in the event of a crash.
More PulseAudio-specific advice is also given at: http://pulseaudio.org/wiki/Community#BugsPatchesTranslations