[alsa-devel] [Fwd: Re: [pulseaudio-discuss] pulseaudio debug mode]
superquad.vortex2 at gmail.com
Mon Jul 26 02:00:57 CEST 2010
2010/7/26 Chris <cpollock at embarqmail.com>
> Raymond, attached is a post I made today to the pulseaudio list.
> KeyID 0xE372A7DA98E6705C
> ---------- 轉寄訊息 ----------
> From: Chris <cpollock at embarqmail.com>
> To: pulseaudio-discuss at 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?
ens1371 is ready to enter running state after PA server call
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
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 )
More information about the Alsa-devel