[pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio

[pierre-louis.bossart at linux.intel.com]

>
>  I've attached the PA config files I am using, along with the log
> output(pulselog).  The most suspicious thing in there is the failure to
> get
> RT scheduling.  Is there something obviously wrong with the configs that
> would cause these numbers to be so high, or to prevent 10ms latency
> working?

Hi Dylan,
Yes, without real-time scheduling it's unlikely that you would get
low-latency results. in your setup, everything is based on system timers
with ALSA interrupts disabled, if there's a delay in handling timer events
chances are you will see underruns, which results in a  latency increase.
Is there any reason why this would fail on Chrome, usually this is only a
configuration issue?

Looking at your log file, I think there's an issue with the buffer
settings. The requested latency is 20ms (tlength, total buffering), but at
the same time the minreq field is also set to 20ms. Minreq defines the
amount of data requested by PulseAudio to the client. You would think that
a double-buffering scheme is needed here. If the two values are equal, I
am not sure things would work well? Chances are that you fell in a corner
case where PulseAudio corrects the values you set to have the latency at
least twice the minreq value?

Also in default.pa you load the alsa-sink/source by hand yet use
module-detect. This looks odd, it's either one or the other?
-Pierre