On Fri, 23.10.09 18:55, Alexandre Savard (alexandre.savard at savoirfairelinux.com) wrote: > We are developing a VOIP phone. > > I upgraded my ubuntu 9.10 Karmic last thursday. Since, I can't get any > audio playback from pulseaudio or very crappy one. There is several > playback buffer underrun occuring. The Alsa plug-in still work well. > Before that upgrade, everything was working just fine. I have pulseaudio > and my application running on a Jaunty 9.10 and there is no problems. > > Looking at the Latency Control > (http://pulseaudio.org/wiki/LatencyControl?version=17): > > I first make sure that PA runs timer scheduling mode (tsched=1) for ALSA > devices. > Is this parameter is the /etc/pulse/daemon.conf "realtime-scheduling = > yes" > > Uncommenting > realtime-scheduling = yes > realtime-priority = 5 > had no effect. You need to have the privs to get RT. Enabling these options just will make PA ask for RT. As mentioned from other folks on this thread unless rtkit is installed or you fiddle with limits.conf or something similar PA won't get RT. > > Using these pstream attributes provide me these debug messages in > pulseaudio: > > attributes->maxlength = (uint32_t) -1; > attributes->tlength = 4096; > attributes->prebuf = (uint32_t) -1; > attributes->minreq = (uint32_t) -1; > attributes->fragsize = (uint32_t) -1; tlength should be configured based on your sample_spec: attributes->tlength = pa_usec_to_bytes(ss, 50 * PA_MSEC_PER_USEC); > D: protocol-native.c: Requesting rewind due to end of underrun. > D: alsa-sink.c: Requested to rewind 196 bytes. > D: alsa-sink.c: Limited to 196 bytes. > D: alsa-sink.c: before: 49 > D: alsa-sink.c: after: 49 > D: alsa-sink.c: Rewound 196 bytes. > D: sink.c: Processing rewind... Hmm, this suggeests that for some reason your client did not provide the necessary number of samples to the sound server in time. How 'fast' do you respond to request callbacks from the server? Do you fulfill the full request you are asked for (i.e. nbytes resp. pa_stream_get_writable_size())? > I: protocol-native.c: Final latency 47.44 ms = 0.50 ms + 2*23.22 ms + > 0.50 ms This second run has the effect that the buffer substantially more in sw than the size of the underlyng hw buffer. Normally, the sw and hw buffers should have the same size, but the smaller you pick your latency the more sw buffer is used in comparison the hw buffering. Hmm, I am a bit puzzled by this. Are the sources open for your stuff? Can i build that locally without too much of a headache? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
