[pulseaudio-discuss] should prebuf always be greater than minreq ?

Alban Browaeys prahal at yahoo.com
Tue Oct 7 20:07:42 PDT 2014


Should prebuf always be greater or equal than minreq ?

I face an issue on an ARM board (cortex A9, odroid with a debian install
upon it ).


That is  with a low requested buffer_size  from the application,
native-protocol fix_playback_buffer_attr up all the fields except prebuf
(as it is not -1 but a value computed from the initial buffer size)

Affected applications are alsaplayer, moc, also aplay if fiddling with
the buffer size to lower the default (after investigation I could
workaround the issue with a up  of the buffer size in its code).


Still the logs when I get underruns that are piling up, never recovered
properly  and sound is weird, it shows : prebuf=2048 minreq=17628 and
tlength=52896


in pulseaudio 5 (debian experimental, that is .0-12) :
src/pulsecore/protocol-native.c fix_playback_buffer_attr ,I now  set
prebuf to at least minreq (at the end of the function for now).

Even alsaplayer (where I was not able to set a high enough buffer, even
in code without extensive rewrite) works with this change.

Mind PULSE_LATENCY_MSEC=60 also workaround the issue, though it looks
like it only does so as it forces the prebuf to tlength (which is always
higher than minreq).


vanilla pulseaudio: broken audio output:
E: [lt-pulseaudio] protocol-native.c: Client requested: maxlength=4194304 bytes tlength=32768 bytes minreq=2048 bytes prebuf=2048 bytes
E: [lt-pulseaudio] protocol-native.c: Client requested: maxlength=23777 ms tlength=185 ms minreq=11 ms prebuf=11 ms
I: [lt-pulseaudio] protocol-native.c: Requested tlength=185,76 ms, minreq=11,61 ms
D: [lt-pulseaudio] protocol-native.c: Early requests mode enabled, configuring sink latency to minreq.
D: [lt-pulseaudio] protocol-native.c: Requested latency=11,61 ms, Received latency=99,95 ms
E: [lt-pulseaudio] protocol-native.c: Client accepted: maxlength=23777 ms tlength=299 ms minreq=99 ms prebuf=11 ms
D: [lt-pulseaudio] memblockq.c: memblockq requested: maxlength=4194304, tlength=52896, base=4, prebuf=2048, minreq=17628 maxrewind=0
D: [lt-pulseaudio] memblockq.c: memblockq sanitized: maxlength=4194304, tlength=52896, base=4, prebuf=2048, minreq=17628 maxrewind=0


modified pulseaudio:
E: [lt-pulseaudio] protocol-native.c: Client requested: maxlength=4194304 bytes tlength=32768 bytes minreq=2048 bytes prebuf=2048 bytes
E: [lt-pulseaudio] protocol-native.c: Client requested: maxlength=23777 ms tlength=185 ms minreq=11 ms prebuf=11 ms
I: [lt-pulseaudio] protocol-native.c: Requested tlength=185,76 ms, minreq=11,61 ms
D: [lt-pulseaudio] protocol-native.c: Early requests mode enabled, configuring sink latency to minreq.
D: [lt-pulseaudio] protocol-native.c: Requested latency=11,61 ms, Received latency=99,95 ms
E: [lt-pulseaudio] protocol-native.c: Client accepted: maxlength=23777 ms tlength=299 ms minreq=99 ms prebuf=99 ms
D: [lt-pulseaudio] memblockq.c: memblockq requested: maxlength=4194304, tlength=52896, base=4, prebuf=17628, minreq=17628 maxrewind=0
D: [lt-pulseaudio] memblockq.c: memblockq sanitized: maxlength=4194304, tlength=52896, base=4, prebuf=17628, minreq=17628 maxrewind=0






More information about the pulseaudio-discuss mailing list