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
