protocol-native: I get endless underruns when I playback when alsa buffer size is small
Submitted by Alban Browaeys
Assigned to pul..@..op.org
Description
On my exynos4 arm board (odroid u2) I cannot playback with most "alsa/oss only" players (moc, alsaplayer, aplay when I set the buffer_size to a small value <= 5000).
Mind if I disable pulseaudio the playback is fine.
At startup underruns occurs and pile up fast. Mind with the workaround told below I also get underruns but they are recovered quite fast .
I found this to be related to the support or no support of dma residue reporting to alsa. It turns out that pl330 DMAC used on this board has not support for residue. Only granularity descriptor. I could confirm as I have a set of patch that had this support and the issue vanish if I enable residue support (via granularity burst). ie at : https://github.com/prahal/linux/commit/6f6cfc5cc1f795526adb2b730154624639845117 and the three patches before this one.
Logs when granularity is BURST or SEGMENT but not DESCRIPTOR (ie odroid u2 with above patch applied, and all other platform I could get my hand on: two amd64 boxes -one intel the other amd64 - and an x86_32 all behaves the same: minreq is equal prebuf , except a few where minreq is below prebuf ).
PS: PULSE_LATENCY_MSEC=60 workaround the issue, though it looks like it only does so as it forces the prebuf to tlength (which is always higher than minreq).
Logs:
-
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: correct audio out. 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
I modified 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).
To sum up there is a way to workaround the issue in the kernel (in avoid no residue , ie granularity DESCRIPTOR).
Mind the client always request a prebuf equal or greater than minreq. Only when heuristics in fix__playback_buffer_attr increase minreq they do not change prebuf).