[pulseaudio-tickets] [Bug 84878] New: protocol-native: I get endless underruns when I playback when alsa buffer size is small

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84878

            Bug ID: 84878
           Summary: protocol-native: I get endless underruns when I
                    playback when alsa buffer size is small
           Product: PulseAudio
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: core
          Assignee: pulseaudio-bugs at lists.freedesktop.org
          Reporter: prahal at yahoo.com
        QA Contact: pulseaudio-bugs at lists.freedesktop.org
                CC: lennart at poettering.net

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).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20141010/fcbd9fc1/attachment.html>