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 msSo, 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