2010/4/19 Lennart Poettering <mznyfn@xxxxxxxxxxx> > On Mon, 19.04.10 13:20, Shuang He (shuang.he@xxxxxxxxx) 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
