https://bugs.freedesktop.org/show_bug.cgi?id=66962
--- Comment #8 from Pierre Ossman <pierre-bugzi...@ossman.eu> --- (In reply to comment #7) > > Do you also experience this in other open source applications, or is Flash > the only one hit by this problem? > I think that Firefox' built in video player also suffered from the issue. Unfortunately this was not the only bug we were struggling with, so we don't have a full picture of which applications were affected by which issues. Given the nature of the bug though, it should be limited to programs relying on the ALSA plugin. > Changing buffering behaviour due to one closed source application feels like > hunting a moving target. What if Flash decides to something differently next > time? Always a risk. But this change is not just about satisfying the whims of Flash. It does make PulseAudio better in a general sense, at least for the ALSA emulation. The current ALSA plugin does not fully satisfy the ALSA API from the applications point of view. Flash just turned out to be more sensitive to violations of the ALSA API than most. IOW, I don't believe this to be a workaround for a bug in Flash. This is a workaround for a limited architecture of the ALSA PulseAudio plugin. The point is to minimise its broken behaviour. A better fix is most likely possible. But not without a lot of work. So this bandaid is low hanging fruit IMO. And proprietary or not, Flash is a very common application. I don't find it acceptable to not have it working. > > > 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. > Indeed. But it's a lot more work and not as easily solved. > > 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. Fair enough. Bluetooth users might be in the risk of regressions. Should be simple enough to test if you have a A2DP device available? -- 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
