[pulseaudio-discuss] changing pa_buffer_attr in pulse's settings possible?

[Lennart Poettering]

On Wed, 23.12.09 15:02, Halim Sahin (halim.sahin at freenet.de) wrote:

> 
> Hi,
> We have developed a libao driver for speech-dispatcher text-to-speech
> server.
> The problem was that if we get short sample like an
> e, i, u pulseaudio didn't play them.
> Adjusting the mentioned value in pa_buffer_attr fixed this.
> Thanks to Bill who has found the problem.
> 
> His approach did the following:
> #define PA_MIN_AUDIO_LENTH 100
> pa_buffer_attr buffAttr;
> buffAttr.maxlength = (uint32_t)-1;
> buffAttr.tlength = PA_MIN_AUDIO_LENTH;
> buffAttr.prebuf = (uint32_t)-1;
> buffAttr.minreq = (uint32_t)-1;
> buffAttr.fragsize =(uint32_t)-1;
> 
> This works great now and without any stuttering or latency.
> Sure I can patch my libao but it will take some time until all distros
> can integrate the changes.
> 
> The question is:
> Wich sideeffects can we expect by setting these vallues in the given
> example?
> 
> Sure an usefull default should be set in pulseaudio.
> But sometimes it would be useful to change the default values in pa's
> setting :-).
> Thanks
> Halim

Last time I check libao (the Xiph version I presume) did have no
control functions for latency, and as such as not useful for
implementing software where latency needs to be controlled which is
probably the case for speech-dispatcher.

So, either extend libao to provide proper latency controls, or stop
using libao in speech-dispatcher since it is simple the wrong library
to build on.

If you patch libao to use a smaller latency by default this might make
it more useful for your particular usecase but otoh will have a
negative effect of all the other apps that use it for trivial audio
playback where latency does not matter but minimal power consumption
does.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4