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

[Pierre-Louis Bossart]

> Makes sense, I'll take a look at what pacat is actually filling the
> buffer attributes with and see if I can track this down. 

here are some additional explanations. Hang on to your hat, this isn't
simple stuff:

pacat has this 'process-time-msec' parameter which defines the min_req
value (not a very good parameter name I agree). I just tried on my
fedora15 box and I can get a latency below 20ms without any issues:

paplay -v --latency-msec=20 --process-time-msec=1 viol-1mn.wav 
Time: 3.703 sec; Latency: 15173 usec.   

The log also shows:
Final latency 20.00 ms = 9.00 ms + 2*1.00 ms + 9.00 ms

Indeed if you don't specify a value for minreq this parameter will be
set to 20ms, and then there's some logic in protocol-native.c to make
sure the latency is 2x the minreq buffer, hence the results you saw. Not
a bug but a feature I'd say...

If you want to control the audio latency in a meaningful way for speech
processing integration, and I guess this is what you are after, you
should start with the desired interval between audio wakes, say 5ms.
This means that a buffering of 10ms in the ALSA ring buffer, and there
will be an additional 10ms buffer in the server. Then you add 2* minreq
to find the total latency.

If you take the reverse path, if you set minreq to 1ms and tlength to
10ms, this means you will have an audio event every 2ms (10-2*1)/2/2.
Note that this logic doesn't apply for larger buffers, this only works
when the latency is below the default watermark level.

Will try to look into cpu usage. One good pointer is to look at
pytimechart (http://gitorious.org/pytimechart), it's a very useful tool
to see graphically what goes on in the system. You can capture a frace
and look at it on your development system. Everyone I know at Intel uses
it to find spurious wakes and silly system behavior. I actually verified
the interval between audio wakes with this tool.

>         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?
> hand loading was just a quick hack to avoid using the alsa "default"
> interface which was going through dmix and wasting cycles.  It's weird
> but I don't think it should hurt performance once it's up and running.

Yes there are issues when using the alsa-lib devices. You will face the
same problem with the 'front' device. If you are using alsa mixer
profiles, I suggest you remove the 'front' device and hard-coded to
hw:0, this will remove the need for changes in init files.