2012-7-19 上午6:14 於 "Matthew Gregan" <<a href="mailto:kinetik@flim.org">kinetik@flim.org</a>> 寫道： > > > 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.