[alsa-devel] [Fwd: Re: [pulseaudio-discuss] pulseaudio debug mode]

[Raymond Yau]

2010/7/26 Chris <cpollock at embarqmail.com>

> Raymond, attached is a post I made today to the pulseaudio list.
>
> --
> Chris
> 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?
>
> 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 )