<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - early request mode breaks with high latency sink" href="https://bugs.freedesktop.org/show_bug.cgi?id=66962#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - early request mode breaks with high latency sink" href="https://bugs.freedesktop.org/show_bug.cgi?id=66962">bug 66962</a> from <a class="email" href="mailto:david.henningsson@canonical.com" title="David Henningsson <david.henningsson@canonical.com>"> David Henningsson</a> <pre>(In reply to <a href="show_bug.cgi?id=66962#c6">comment #6</a>) > (In reply to <a href="show_bug.cgi?id=66962#c5">comment #5</a>) > > So, I think there are two things that's currently keeping me from applying > > this patch. > > > > 1) Understanding. I'm not sure I understand what it is within Flash's way of > > handling its audio flow that causes the existing implementation to fail. > > > > The specifics aren't known. It being proprietary isn't exactly helping in > analysing the issue. Do you also experience this in other open source applications, or is Flash the only one hit by this problem? Changing buffering behaviour due to one closed source application feels like hunting a moving target. What if Flash decides to something differently next time? > My guess is that it is either using some kind of timer to handle audio > and/or has its own internal buffer. It configures alsa with e.g. 50 ms > fragment size. It then expects that every 50 ms it can provide more data and > everything is fine. But PulseAudio only requests data e.g. every 400 ms. So > after those 50 ms are up, Flash stops buffering and waits for ALSA to wake > up. The end result being underruns. If those are realistic numbers, it sounds like we more need to do the timing thing in the ALSA plugin, rather than the bandaid you provided. > > 2) Fear of regressions. My bad experience tells me that when you fix one > > scenario you break another. This patch, AFAIK, has had very limited testing > > across both applications and hardware. > > Always a risk. On the plus side this will only affect a very small number of > cases. You have to a) have a client that requests the early request mode, > and b) have a sink that cannot configure itself for low latency. For a), as you know ALSA-plugin is using the early request mode, and there are *a lot* of ALSA application. For b), I think bluetooth a2dp would be a reasonably common high latency sink scenario. > So given that it's mostly corner cases, I don't see how to get any > reasonable testing of this without exposing it to the world. See above.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>