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

[Colin Guthrie]

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/