Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-27 Thread xing wang
Hi tanuk,

Let me quote piece of your post:
Are there any real problems with this rewinding, like the beginning of
the stream disappearing, or an audible drop-out in the audio? The sink
buffer has to be always rewound when a new stream is created, because
initially the sink buffer contains silence. That silence has to be
overwritten with the stream data, so that there's no unnecessary latency
due to waiting for the silence to be played.

If the buffer_size is bigger enough, such as 2s, at the beginning of
stream starting playback, there's only silence, right? For music
playing, it maybe accetable for user.But for
video playing, this obvious delay makes Video/Audio out of sync.

I am not sure whether catch your point clearly.

--xingchao

2011/5/26 xing wang wangxingchao2...@gmail.com:
 2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 10:42 did gyre and gimble:
 2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

 Just as a very small aside, David did some work on Fighting Rewinds
 recently.

 Just search the stable-queue git log for Fighting rewinds...

 These may already be included in your build, but if not it's perhaps
 worth grabbing those patches?

 Thank you Colin, let me have a try.

 Of course it's probably sensible to just run the whole stable-queue
 branch. That's generally what I do in my distro packages... just apply
 all stable queue patches on top of the official release. A 0.9.23
 release will likely go out soon (if I can nail Lennart down!) based on
 this branch.

 Hi Colin, i think my release had include David's patchset.  I see
 there're three patches about Fast rewind, here's the link:
 http://gstreamer-devel.966125.n4.nabble.com/Fighting-rewinds-pulseaudio-crash-update-td3248107.html.

 The delay issue met based on my release build could not be fixed with
 David's patch.
 But i think it's quite like Ccrma's description in post rewind and
 underrun issues on start of playback.  If change the buffer size to
 smaller value, the delay becomes short. I am not sure whether alsa is
 playing silence data or just didnot start playback.

 Thanks
 --xingchao


 Col


 --

 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/

 Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
 Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread xing wang
Hi baeksan,

Accidently I see your post about Pulseaudio rewind issue, that's quite
same with mine.
The background is, with timer-based feature enabled, i use default
2000ms  of tsched_size, when playback begins
there's rewind operation because of application's request latency very
low,so the final buffer size will be a small value after calculation.
then there will be nearly 3 seconds before hear the real sound. Maybe
alsa is playing silence data or didnot start to playback operations.

From your log i see the buffer_size/period_size is not too big, so do
you have try with a big tsched_size value(such as 2 second). if we
have same result, that's maybe Pulseaudio's bug about the rewind operations.

--xingchao




=
From baeksan at ccrma.stanford.edu  Sun May  1 00:38:34 2011
From: baeksan at ccrma.stanford.edu (Baek Chang)
Date: Sat, 30 Apr 2011 15:38:34 -0700
Subject: [pulseaudio-discuss] rewind and underrun issues on start of playback
Message-ID: banlktikq1u6duzzikgfqgs0ofm2mkc5...@mail.gmail.com

Hi,

I'm seeing some issue with underruns/rewinds occurring on the beginning of
every sink input playback.
I see rewind requests on alsa sink of 9600 bytes.  The alsa driver is
configured with the following buffer sizes

I: sink.c: device.buffering.buffer_size = 9600
I: sink.c: device.buffering.fragment_size = 4800

So it seems like one buffer size is always being rewinded on the beginning
of playback.
Is there a way to prevent these rewinds/underruns when starting playback?
 after the stream has started, there is no issue with audio dropouts or
underruns, just on the beginning.

If i log the data that gets sent to alsa, from pulseaudio or in the alsa
driver, i do see the beginning being dropped as well.

please see attached logs using both tshed=0 and tsched=1.

any help with this?
thanks!

I: client.c: Created 0 Native client (UNIX socket client)
D: protocol-native.c: Protocol version: remote 19, local 19
I: protocol-native.c: Got credentials: uid=0 gid=0 success=1
D: protocol-native.c: SHM possible: yes
D: protocol-native.c: Negotiated SHM: no
D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=4,
prebuf=0, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=33554432, tlength=33554432,
base=4, prebuf=0, minreq=4 maxrewind=0
I: sink-input.c: Created input 0 /usr/palm/sounds/notification.wav on
pcm_output with sample spec s16le 2ch 44100Hz and channel map
front-left,front-right
I: sink-input.c: media.format = WAV (Microsoft)
I: sink-input.c: media.name = /usr/palm/sounds/notification.wav
I: sink-input.c: application.name = pacat
I: sink-input.c: native-protocol.peer = UNIX socket client
I: sink-input.c: native-protocol.version = 19
I: sink-input.c: application.process.id = 4474
I: sink-input.c: application.process.user = root
I: sink-input.c: application.process.host = PalmDevice
I: sink-input.c: application.process.binary = pacat
I: sink-input.c: application.language = C
I: sink-input.c: application.process.machine_id = PalmDevice
I: protocol-native.c: Requested tlength=2000.00 ms, minreq=20.00 ms
D: protocol-native.c: Traditional mode enabled, modifying sink usec only for
compat with minreq.
D: memblockq.c: memblockq requested: maxlength=4194304, tlength=352800,
base=4, prebuf=349276, minreq=3528 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=352800,
base=4, prebuf=349276, minreq=3528 maxrewind=0
I: protocol-native.c: Final latency 2054.42 ms = 1960.00 ms + 2*20.00 ms +
54.42 ms
D: protocol-native.c: Requesting rewind due to end of underrun.
D: alsa-sink.c: Requested to rewind 9600 bytes.
D: alsa-sink.c: Limited to 9344 bytes.
D: alsa-sink.c: before: 2336
D: alsa-sink.c: after: 2336
D: alsa-sink.c: Rewound 9344 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 9344 bytes on render memblockq.
D: source.c: Processing rewind...
D: protocol-native.c: Underrun on '/usr/palm/sounds/notification.wav', 0
bytes in queue.
D: alsa-sink.c: Requested to rewind 9600 bytes.
D: alsa-sink.c: Limited to 9344 bytes.
D: alsa-sink.c: before: 2336
D: alsa-sink.c: after: 2336
D: alsa-sink.c: Rewound 9344 bytes.
D: sink.c: Processing rewind...
D: source.c: Processing rewind...
D: core.c: Hmm, no streams around, trying to vacuum.
I: sink-input.c: Freeing input 0 /usr/palm/sounds/notification.wav
I: client.c: Freed 0 pacat
I: protocol-native.c: Connection died.

-- 
-baeksanchang
-- next part --
An HTML attachment was scrubbed...
URL: 
https://tango.0pointer.de/pipermail/pulseaudio-discuss/attachments/20110430/97c1f9a4/attachment-0001.htm
-- next part --
root at PalmDevice:/media/internal# pulseaudio -
D: core-rtclock.c: Timer slack is set to 50 us.
D: core-util.c: setpriority() worked.
I: core-util.c: Successfully gained nice level -4.
I: main.c: Found user 'pulse' (UID 31) and 

Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread Colin Guthrie
'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

Just as a very small aside, David did some work on Fighting Rewinds
recently.

Just search the stable-queue git log for Fighting rewinds...

These may already be included in your build, but if not it's perhaps
worth grabbing those patches?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread xing wang
2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

 Just as a very small aside, David did some work on Fighting Rewinds
 recently.

 Just search the stable-queue git log for Fighting rewinds...

 These may already be included in your build, but if not it's perhaps
 worth grabbing those patches?

Thank you Colin, let me have a try.

--xingchao

 Col


 --

 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/

 Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
 Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread Colin Guthrie
'Twas brillig, and xing wang at 26/05/11 10:42 did gyre and gimble:
 2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

 Just as a very small aside, David did some work on Fighting Rewinds
 recently.

 Just search the stable-queue git log for Fighting rewinds...

 These may already be included in your build, but if not it's perhaps
 worth grabbing those patches?
 
 Thank you Colin, let me have a try.

Of course it's probably sensible to just run the whole stable-queue
branch. That's generally what I do in my distro packages... just apply
all stable queue patches on top of the official release. A 0.9.23
release will likely go out soon (if I can nail Lennart down!) based on
this branch.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread xing wang
2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 10:42 did gyre and gimble:
 2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

 Just as a very small aside, David did some work on Fighting Rewinds
 recently.

 Just search the stable-queue git log for Fighting rewinds...

 These may already be included in your build, but if not it's perhaps
 worth grabbing those patches?

 Thank you Colin, let me have a try.

 Of course it's probably sensible to just run the whole stable-queue
 branch. That's generally what I do in my distro packages... just apply
 all stable queue patches on top of the official release. A 0.9.23
 release will likely go out soon (if I can nail Lennart down!) based on
 this branch.

Hi Colin, i think my release had include David's patchset.  I see
there're three patches about Fast rewind, here's the link:
http://gstreamer-devel.966125.n4.nabble.com/Fighting-rewinds-pulseaudio-crash-update-td3248107.html.

The delay issue met based on my release build could not be fixed with
David's patch.
But i think it's quite like Ccrma's description in post rewind and
underrun issues on start of playback.  If change the buffer size to
smaller value, the delay becomes short. I am not sure whether alsa is
playing silence data or just didnot start playback.

Thanks
--xingchao


 Col


 --

 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/

 Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
 Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-03 Thread Colin Guthrie
'Twas brillig, and Baek Chang at 02/05/11 04:52 did gyre and gimble:
 Also, if i revert to pulseaudio 0.9.14, i do not see this issue
 happening.  I can hear the very short samples in the beginning fine.

I think generally that the rewinding should work, and that by reverting
you are just bypassing a bug at (perhaps) the alsa level which should
really be fixed.

I suspect if you can create a (very simple) alsa test application that
exhibits the problem (by using rewinds) then this can be taken to the
alsa-devel list in order to fix the underlying problem.

That's my take on it anyway, and I could of course be wrong!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-03 Thread Baek Chang
I think you are correct in that there is an alsa bug.  It seems that
pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio
0.9.22 does.
It seems like the rewind is causing the driver to not have data in its first
hw buffer, the dropout in the beginning is a hw buffer size.

Thanks

On Tue, May 3, 2011 at 1:36 AM, Colin Guthrie gm...@colin.guthr.ie wrote:

 'Twas brillig, and Baek Chang at 02/05/11 04:52 did gyre and gimble:
  Also, if i revert to pulseaudio 0.9.14, i do not see this issue
  happening.  I can hear the very short samples in the beginning fine.

 I think generally that the rewinding should work, and that by reverting
 you are just bypassing a bug at (perhaps) the alsa level which should
 really be fixed.

 I suspect if you can create a (very simple) alsa test application that
 exhibits the problem (by using rewinds) then this can be taken to the
 alsa-devel list in order to fix the underlying problem.

 That's my take on it anyway, and I could of course be wrong!

 Col

 --

 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/

 Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
 Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss




-- 
-baeksanchang
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-03 Thread Mark Brown
On Tue, May 03, 2011 at 11:09:56AM -0700, Baek Chang wrote:
 I think you are correct in that there is an alsa bug.  It seems that
 pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio
 0.9.22 does.
 It seems like the rewind is causing the driver to not have data in its first
 hw buffer, the dropout in the beginning is a hw buffer size.

I frequently recommend PulseAudio as a test suite for driver DMA
implementations :)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-03 Thread Dan Muresan
 I think you are correct in that there is an alsa bug.  It seems that
 pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio
 0.9.22 does.

I asked before, but for some reason never got an answer from this
list: is there a simple way to disable rewinds? They seem to be
related to excessive real-time CPU usage, causing rlimit_rttime to be
exceeded (and pulse to be KILL'ed by the kernel).

-- Dan
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-03 Thread Colin Guthrie
Hi,

'Twas brillig, and Dan Muresan at 03/05/11 19:51 did gyre and gimble:
 I think you are correct in that there is an alsa bug.  It seems that
 pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio
 0.9.22 does.
 
 I asked before, but for some reason never got an answer from this
 list: is there a simple way to disable rewinds? They seem to be
 related to excessive real-time CPU usage, causing rlimit_rttime to be
 exceeded (and pulse to be KILL'ed by the kernel).

From earlier in this thread:

'Twas brillig, and Tanu Kaskinen at 01/05/11 08:22 did gyre and gimble:
 On Sat, 2011-04-30 at 15:38 -0700, Baek Chang wrote:
  Is there a way to prevent these rewinds/underruns when starting
playback?

 Not to my knowledge, except by changing the code.


I'm pretty sure that's correct (tho' I won't pretend to know the alsa
code in very much depth).

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-01 Thread Baek Chang
Also, if i revert to pulseaudio 0.9.14, i do not see this issue happening.
 I can hear the very short samples in the beginning fine.

On Sun, May 1, 2011 at 8:45 PM, Baek Chang baek...@ccrma.stanford.eduwrote:

 I am hearing that very very short sounds, smaller than hw buffer size,
 occasionally not heard.  The initial portion of audio is silenced.  If i
 remove the rewind request from protocal-native.c, then the problem is
 resolved, but other issues are there, audible glitches when doing volume
 changes.


 On Sun, May 1, 2011 at 12:22 AM, Tanu Kaskinen ta...@iki.fi wrote:

 On Sat, 2011-04-30 at 15:38 -0700, Baek Chang wrote:
  Hi,
 
  I'm seeing some issue with underruns/rewinds occurring on the beginning
 of
  every sink input playback.
  I see rewind requests on alsa sink of 9600 bytes.  The alsa driver is
  configured with the following buffer sizes
 
  I: sink.c: device.buffering.buffer_size = 9600
  I: sink.c: device.buffering.fragment_size = 4800
 
  So it seems like one buffer size is always being rewinded on the
 beginning
  of playback.
  Is there a way to prevent these rewinds/underruns when starting
 playback?

 Not to my knowledge, except by changing the code.

   after the stream has started, there is no issue with audio dropouts or
  underruns, just on the beginning.
 
  If i log the data that gets sent to alsa, from pulseaudio or in the alsa
  driver, i do see the beginning being dropped as well.
 
  please see attached logs using both tshed=0 and tsched=1.
 
  any help with this?
  thanks!

 Are there any real problems with this rewinding, like the beginning of
 the stream disappearing, or an audible drop-out in the audio? The sink
 buffer has to be always rewound when a new stream is created, because
 initially the sink buffer contains silence. That silence has to be
 overwritten with the stream data, so that there's no unnecessary latency
 due to waiting for the silence to be played.

 That said, the underrun seems strange, because it happens after the
 Requesting rewind due to end of underrun message. I don't know the
 code well enough to be sure that it indicates any error, though. If the
 messages would be ordered the other way around, then it would make more
 sense: first when the stream is created, the buffer doesn't have any
 data, but when the prebuffering phase ends, then a rewind is requested
 on the sink to allow the stream playback to start immediately.

 I don't know if this was helpful at all...

 --
 Tanu

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss




 --
 -baeksanchang




-- 
-baeksanchang
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


[pulseaudio-discuss] rewind and underrun issues on start of playback

2011-04-30 Thread Baek Chang
Hi,

I'm seeing some issue with underruns/rewinds occurring on the beginning of
every sink input playback.
I see rewind requests on alsa sink of 9600 bytes.  The alsa driver is
configured with the following buffer sizes

I: sink.c: device.buffering.buffer_size = 9600
I: sink.c: device.buffering.fragment_size = 4800

So it seems like one buffer size is always being rewinded on the beginning
of playback.
Is there a way to prevent these rewinds/underruns when starting playback?
 after the stream has started, there is no issue with audio dropouts or
underruns, just on the beginning.

If i log the data that gets sent to alsa, from pulseaudio or in the alsa
driver, i do see the beginning being dropped as well.

please see attached logs using both tshed=0 and tsched=1.

any help with this?
thanks!

I: client.c: Created 0 Native client (UNIX socket client)
D: protocol-native.c: Protocol version: remote 19, local 19
I: protocol-native.c: Got credentials: uid=0 gid=0 success=1
D: protocol-native.c: SHM possible: yes
D: protocol-native.c: Negotiated SHM: no
D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=4,
prebuf=0, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=33554432, tlength=33554432,
base=4, prebuf=0, minreq=4 maxrewind=0
I: sink-input.c: Created input 0 /usr/palm/sounds/notification.wav on
pcm_output with sample spec s16le 2ch 44100Hz and channel map
front-left,front-right
I: sink-input.c: media.format = WAV (Microsoft)
I: sink-input.c: media.name = /usr/palm/sounds/notification.wav
I: sink-input.c: application.name = pacat
I: sink-input.c: native-protocol.peer = UNIX socket client
I: sink-input.c: native-protocol.version = 19
I: sink-input.c: application.process.id = 4474
I: sink-input.c: application.process.user = root
I: sink-input.c: application.process.host = PalmDevice
I: sink-input.c: application.process.binary = pacat
I: sink-input.c: application.language = C
I: sink-input.c: application.process.machine_id = PalmDevice
I: protocol-native.c: Requested tlength=2000.00 ms, minreq=20.00 ms
D: protocol-native.c: Traditional mode enabled, modifying sink usec only for
compat with minreq.
D: memblockq.c: memblockq requested: maxlength=4194304, tlength=352800,
base=4, prebuf=349276, minreq=3528 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=352800,
base=4, prebuf=349276, minreq=3528 maxrewind=0
I: protocol-native.c: Final latency 2054.42 ms = 1960.00 ms + 2*20.00 ms +
54.42 ms
D: protocol-native.c: Requesting rewind due to end of underrun.
D: alsa-sink.c: Requested to rewind 9600 bytes.
D: alsa-sink.c: Limited to 9344 bytes.
D: alsa-sink.c: before: 2336
D: alsa-sink.c: after: 2336
D: alsa-sink.c: Rewound 9344 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 9344 bytes on render memblockq.
D: source.c: Processing rewind...
D: protocol-native.c: Underrun on '/usr/palm/sounds/notification.wav', 0
bytes in queue.
D: alsa-sink.c: Requested to rewind 9600 bytes.
D: alsa-sink.c: Limited to 9344 bytes.
D: alsa-sink.c: before: 2336
D: alsa-sink.c: after: 2336
D: alsa-sink.c: Rewound 9344 bytes.
D: sink.c: Processing rewind...
D: source.c: Processing rewind...
D: core.c: Hmm, no streams around, trying to vacuum.
I: sink-input.c: Freeing input 0 /usr/palm/sounds/notification.wav
I: client.c: Freed 0 pacat
I: protocol-native.c: Connection died.

-- 
-baeksanchang
root@PalmDevice:/media/internal# pulseaudio -
D: core-rtclock.c: Timer slack is set to 50 us.
D: core-util.c: setpriority() worked.
I: core-util.c: Successfully gained nice level -4.
I: main.c: Found user 'pulse' (UID 31) and group 'pulse' (GID 31).
I: main.c: Successfully dropped root privileges.
I: main.c: This is PulseAudio 0.9.22
D: main.c: Compilation host: arm-none-linux-gnueabi
D: main.c: Compilation CFLAGS: -isystem 
/home/reviewdaemon/projects/nova/oe/BUILD-topaz/staging/arm-none-linux-gnueabi/include
 -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 
-fno-strict-aliasing -fno-inline-functions -O3 -g -Wimplicit -O3 -Wall -W 
-Wextra -pipe -Wno-long-long -Winline -Wvla -Wno-overlength-strings 
-Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op -Wsign-compare 
-Wformat-security -Wmissing-include-dirs -Wformat-nonliteral 
-Wold-style-definition -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes 
-Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn 
-Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings 
-Wno-unused-parameter -ffast-math -Wp,-D_FORTIFY_SOURCE=2 -fno-common 
-fdiagnostics-show-option
D: main.c: Running on host: Linux armv7l 2.6.35-palm-tenderloin #98 SMP PREEMPT 
Sat Apr 30 12:46:55 PDT 2011
D: main.c: Found 2 CPUs.
I: main.c: Page size is 4096 bytes
D: main.c: Compiled with Valgrind support: yes
D: main.c: Running in valgrind mode: no
D: main.c: Running in VM: no
D: main.c: