Hi, [I'm just concerned that Taylor is not on the PA mailing list so we need to keep them CC'ed. Dylan is registered but CC'ing for completeness :) This message just quotes Pierre-Louis's mail in full below (which is certainly worth reading!) This is my only comment] 'Twas brillig, and Pierre-Louis Bossart at 07/10/11 22:31 did gyre and gimble: >> 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. -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
