<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - early request mode breaks with high latency sink"
href="https://bugs.freedesktop.org/show_bug.cgi?id=66962">66962</a>
</td>
</tr>
<tr>
<th>CC</th>
<td>lennart@poettering.net
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pulseaudio-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>early request mode breaks with high latency sink
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>pulseaudio-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Reporter</th>
<td>pierre-bugzilla@ossman.eu
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>clients
</td>
</tr>
<tr>
<th>Product</th>
<td>PulseAudio
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=82483" name="attach_82483" title="early-request-bandaid.patch">attachment 82483</a> <a href="attachment.cgi?id=82483&action=edit" title="early-request-bandaid.patch">[details]</a></span>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>