<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - High latency in HTTP streaming" href="https://bugs.freedesktop.org/show_bug.cgi?id=65703#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - High latency in HTTP streaming" href="https://bugs.freedesktop.org/show_bug.cgi?id=65703">bug 65703</a> from <a class="email" href="mailto:wangxingchao2011@gmail.com" title="Wang Xingchao <wangxingchao2011@gmail.com>"> Wang Xingchao</a> <pre>(In reply to <a href="show_bug.cgi?id=65703#c14">comment #14</a>) > There are a few points of latency in this. The first is in PulseAudio, > there's some in the network itself (but this is relatively low), and then > there's some in the UPnP client itself. > > You could probably eliminate the client buffering (or at least make it > deterministic) by just opening the HTTP stream directly (look at > <a href="http://localhost:4714/">http://localhost:4714/</a>). > > I am able to reproduce some large latency with this as well on my laptop, so > this eliminates both the network and the client to some extent, but is still > in the "few seconds" range, which is not that great. > > Now the latency in PulseAudio is basically caused by points where we are > buffering data, so this should be something to look at. Hi Arun/Amar Akshat, Do you have guide to reproduce this issue within a simple test environment? I donot have uPnp devices and no Rygel setup yet. But i think if focus on Pa's http-module and module-rygel-media-server, maybe can find new clues. According to <a href="show_bug.cgi?id=65703#c17">comment#17</a>, sounds PA was blocked by something strange and client buffering increased to a high latency value. So if we can reproduce/test this issue within a simple model, it should be convenient to reproduce it. --xingchao</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>