[pulseaudio-discuss] pulseaudio debug mode

Colin Guthrie gmane at colin.guthr.ie
Tue Jul 27 00:37:37 PDT 2010

'Twas brillig, and Chris at 26/07/10 23:40 did gyre and gimble:
> On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble:
>>> What is the best way to start PA for debugging and still have all the
>>> usual clients running?
>> If you mean having all the clients connect (e.g. applications with
>> libcanberra support or similar for sound events), then there are
>> basically two ways.
>> The first is as Luke suggests. These clients will automatically
>> reconnect to PA if they need to (provided you have a vaguely recent
>> libcanberra), after it is restarted and run in debug mode.
>> Alternatively you can simply set debug-level to "debug" in daemon.conf
>> (in /etc/pulse or ~/.pulse), and then "grep pulseaudio /var/log/messages"
>> Col
> Colin, the link below is for some more debug output. Notice in the first
> section that 8 seconds after spamd starts processing a message the the
> Alsa error starts, 2 seconds after that the overruns start. Notice in
> line 145 that it took 145 seconds to process a message, that's about 125
> too long. I've noticed that when I start getting the overrun errors that
> the processing of a message takes forever, though this doesn't happen
> every time, just periodically. All I know is that while this is going on
> the drive is constantly being accessed for minutes at a time in the
> first case from 9:03 to 9:08.
> http://pastebin.com/tZNYaqRV

OK, I'll prepare some packages for you so that we can start to isolate
what queue it is that is causing the problem.



Colin Guthrie

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

More information about the pulseaudio-discuss mailing list