[pulseaudio-discuss] PulseAudio unstable on Ubuntu Karmic 9.10

[Lennart Poettering]

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