2012-7-19 上午6:14 於 "Matthew Gregan" kinetik@flim.org 寫道：
No, it's just a random value for media playback. In an older version of
the
audio backend we're using in Firefox (which was push rather than pull based), we used 500ms and hadn't run into this problem in a way that was obvious to users (i.e. causing broken playback). I chose a lower latency for media playback in the new backend in an attempt to flush out bugs
before
we introduce features that demand low latency (such as WebRTC).
Could you clarify what versions of PulseAudio and alsa-plugins you're using? The latest improvement to this handling was done less than a year ago and might require the latest versions of these components.
I'm using Fedora 17, which has alsa-plugins-pulseaudio-1.0.25-3.fc17 and pulseaudio-1.1-9.fc17. This was originally discovered by users running ALSA 1.0.25 on various distros (Ubuntu 12.04 LTS and Arch). Two of them happened to have a PA server where the latency had crept up over time,
and a
third was running the server with tsched=0 on an Audigy SE (CA0106) with a minimum latency of 200ms.
without using adjust latency mode, pa server use maximum buffer size by default and latency is fixed at about 340ms for ca0106 which does not support 44100hz.
so this is incorrect for pulse plugin to accept 200ms, in previous version of pulseaudio you can specify the fragment time and the number of fragments to achieve low latency.