2010/7/26 Chris cpollock@embarqmail.com

Raymond, attached is a post I made today to the pulseaudio list.

-- Chris KeyID 0xE372A7DA98E6705C

---------- 轉寄訊息 ---------- From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode 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, link below is for debug output also some other output. Anything look out of place that would cause the overruns?

http://pastebin.com/ZWSWmXZt

ens1371 is ready to enter running state after PA server call snd_pcm_hw_params()

The PA server only call snd_pcm_dump() at the probing phase to create working profile for the alsa sound cards, and snd_pcm_dump() indicate that appl_ptr is behind hw_ptr, but the playing thread is started after snd_pcm_dump() .

This mean that some PA clients had connected and send audio to PA server before the first sink finished it setup since ens1371 is card 0 ( the fist sink device )