On Wed, 23.12.09 15:16, Halim Sahin (halim.sahin at freenet.de) wrote: > > Hi, > The latency wasn't the problem. > The playback can be stopped and start quickly > It's the prebuffering. Pulse start playback after it got enough samples. > E. G. > > e is not enough. > v is enough. > Typing one e produces nothing. Typing two produces e e . > > Maybe you have another idea to solve the problem instead patching > pulse/or libao. Oh, are you suggesting that your sw simply writes a blob of data and then stops and the later on goes again? It's kinda ugly to do that since you keep a stream open which ultimately means the audio device cannot be powered down in between. Also, writing an audio client where the buffer underrun is the common case and supplying audio data is the exception is kinda mislead anyway. You should either fill the pauses with silence PCM data, or suspend/close the audio device when you are done. This will also fix the prebuf issue for you. Also, the prebuf stuff will be a problem with all backends, not just PA. Since the libao API is as simple as it is there is no _trigger() call or suchlike which could be used to actually start playback. > If not I would patch libao and add some config options for pulse plugin > (if xiph people are interested in). My recommendation is to fix you app not to keep the audio device open. That simply has the effect of wasting power. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
