Distribution kernels and glitch-free (Packagers, read this!)

[hanke@xxxxxxxxxxxx (Hynek Hanke)]

Lennart Poettering napsal(a):
> Sounds like a bug. Any chance you retest this with 0.9.15. the latency
> configuration changed considerably between 0.9.14 and .15.
>   

Hi Lennart,

we have tested it with 0.9.15 and got much better results.
Basically, it became fast enough with speech-dispatcher
now to be usable for accessibility. This is great!

We are now at about 20ms latency with the 0.00+2*9.98+0.00
values if we set tlength small enough, but without any glitches.
Cool! I still don't understand the zeros, but it seems to work.

I'd like to ask how the connection settings influence the 3 buffer
lengths. Can we still do something to diminish the 9.98ms?
This seems to be the lowest value we can get regardless of
tlength and prebuf settings.

We are currently initializing the connection like this:

 pa_buffer_attr a_attr;
  a_attr.maxlength = id->pulse_max_length;
  a_attr.tlength = id->pulse_target_length;
  a_attr.prebuf = id->pulse_pre_buffering;
  a_attr.minreq = id->pulse_min_request;
  a_attr.fragsize = 0;

  if (pa_stream_connect_playback(id->pulse_stream, NULL, &a_attr, 
(pa_stream_flags_t)(PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE), 
&id->pulse_volume, NULL) < 0) {
    ERR("Failed to connect stream: %s", 
pa_strerror(pa_context_errno(id->pulse_context)));
    goto unlock_and_fail;

where the parameters are:

AudioPulseMaxLength 132300
AudioPulseTargetLength 400
AudioPulsePreBuffering 200
AudioPulseMinRequest 880

What strategy would you recommend to further minimize the total latency?

Thank you,
Hynek Hanke