[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