[pulseaudio-tickets] [Bug 66962] New: early request mode breaks with high latency sink

[bugzilla-daemon at freedesktop.org]

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

          Priority: medium
            Bug ID: 66962
                CC: lennart at poettering.net
          Assignee: pulseaudio-bugs at lists.freedesktop.org
           Summary: early request mode breaks with high latency sink
        QA Contact: pulseaudio-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: pierre-bugzilla at ossman.eu
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: clients
           Product: PulseAudio

Created attachment 82483
  --> https://bugs.freedesktop.org/attachment.cgi?id=82483&action=edit
early-request-bandaid.patch

As it is implemented, the early request mode can in some cases be
counter-productive. The mode is designed to give the client a steady
request/report rate of small-ish chunks[1].

Unfortunately PulseAudio does not have any mechanism for telling a sink/source
how often it should request/report data. So a more blunt hack was applied where
the entire latency is restricted to the fragment size.

So far so good, but where the current code breaks down is when the sink cannot
satisfy this tiny latency request. We then "report" to the client what we can
guarantee by setting the fragment size to the sink's/source's full buffer
size/latency.

This severely changes the resulting buffer attributes from what the client
requested, and in practice breaks applications. The most prominent user of this
feature is the ALSA plugin, and it doesn't even have a mechanism of adapting to
the server giving back something different than what was requested.


So long term, the whole early request mode needs to be implemented in a better
way. Either the sink's/source's need to grow the ability to control
request/report rate. Or we put some form of timer based emulation in front of
them on behalf of these clients.


Short term, we should change the behaviour of what happens when we cannot
guarantee a fragment rate. Instead of giving the client really shitty buffering
parameters as a result, we should just keep the requested attributes and do
things on a best-effort basic. Basically how things would behave if the client
didn't have the early request bit at all.

The attached patch does just that, as well as expand on the comment about how
the early request thing is implemented.


[1] A somewhat silly client requirement but at least Flash and Firefox break
horribly when you break this.

-- 
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/20130716/860004f3/attachment.html>