> 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.
