Re: [pulseaudio-discuss] pulseaudio eats 19% CPU power in Fedora 12

[Raymond Yau <superquad.vortex2@gmail.com>]

2010/4/19 Lennart Poettering <mznyfn@0pointer.de>

> On Mon, 19.04.10 13:20, Shuang He (shuang.he@intel.com) wrote:
>
> Please stop the cross-posting.
> >
>
> >         current latency: 444.25 ms
> >         requested latency: 31.25 ms
>
> So, this is interesting: the client requested 30ms (which is needlessly
> low, but that's another question), but the server ended up providing
> only 444 ms! That is incredibly high and points to the fact that PA
> probably ran into quite a few dropouts before this, presumably due to
> incorrect timing or suchlike, and hence bumped up the minimal latency
> all the time, and bumped down the sleeping time, hence eincreasing the
> CPU load. Almost certainly your audio driver is at fault here.
>
> Check syslog for any comments about that.
>
> Lennart
>
>
when using -ao oss or -ao alsa , mplayer use 16 fragments  and use 0.5
second for the buffer time .  about 31.25ms period time is quite normal

for hda driver which has a constraint of period size must be multiple of 128
bytes ( pcie brust size ) ,

cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 1024
buffer_size: 16384

In his case , mplayer is using alsa-pulse plugin and pulse device has no
specific constraint on hw_params , so 31.25 ms is normal since PA did not
reject the 0.5 seconds and 16 periods

since mplayer is no using pulse api , of course it will not adjust the
latency since pulse device is emulate an alsa hardware device