https://bugs.freedesktop.org/show_bug.cgi?id=66962
--- Comment #6 from Pierre Ossman <pierre-bugzi...@ossman.eu> --- (In reply to comment #5) > 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. 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. > 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. 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. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.
_______________________________________________ pulseaudio-bugs mailing list pulseaudio-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
