With default firefox 41.0.1,1 and alsa-plugins 1.0.29, firefox has high cpu usage when playing html5 video. With an i7-3612QM, firefox uses >130% CPU when playing 720p youtube video. If I enable BUFSZ_P2 for audio/alsa-plugins, CPU usage reduces to ~50%. If I switch to other backends for alsa(like pulse), CPU usage also reduces. Please set the default value of BUFSZ_P2 to "ON" for alsa-plugins, or fix alsa's oss backend.
BUFSZ_P2 is a compatibility hack for audio/alsa-plugins/files/alsa-plugins.patch. When enabled it causes assertion-crash in aplay(1) from audio/alsa-utils. Only gecko@ ports appear to be fragile with ariff's improvements for alsa-plugins-oss which mi tried to fix in bug 196051. As a workaround try to comment out EXTRA_PATCHES line in alsa-plugins port to bring experience closer to OSS on Linux. Current defaults are balanced due to lack of package flavor support or option requirements in dependencies. Better approach is to enable PULSEAUDIO by default (already in configure.in) until OSS is polished enough to land upstream: media/libcubeb used for mainly HTML5 audio playback and media/webrtc/trunk/webrtc/modules/audio_device for device enumeration, capture & playback in WebRTC. files/1021761 already contains partial support, so when you build Firefox against PULSEAUDIO but don't launch the server it'd fallback to OSS backend, same for ALSA if later uninstalled - see cubeb_init().
I tried to comment out the patch, and + OSS still works, CPU usage is low - When a HTML5 video is paused, it can't be resumed But if you do a seek, it will resume at the seek position So for now I'll live with the BUFSZ_P2.
(In reply to Jan Beich from comment #1) I am another user of www/firefox who can verify that the stock alsa-plugins without BUFSZ_P2 causes www/firefox to use more than 100% CPU when playing videos. Anyway, the total effect of not having this bug fixed is that now FreeBSD users do not have a properly working, modern, full-featured browser. The reason for my claim is that the other full-featured browser would be www/chromium, but it is also buggy and unstable, since tabs often crash. There's also a bounty for fixing www/chromium, which I am trying to help fix as a non-professional, but nothing has been done to fix it thus far (see: https://github.com/gliaskos/freebsd-chromium/issues/40). As a sidenote: I am trying to get a core dump from crashing tabs in chromium, but have not been successful yet (because I am not a professional software developer). Because of the total effect this bug has on the few desktop users of FreeBSD, I would suggest creating a clone of alsa-plugins, let's call it alsa-plugins-gecko, in which the BUFSZ_P2 is forced on by default, and having www/firefox link against alsa-plugins-gecko until a proper solution is found. Creating a BUFZS_P2 clone of alsa-plugins would have no negative side effects, since only gecko ports would link against it. Later, when the actual issue has been resolved and when it can be proven that www/firefox works well with the stock alsa-plugins, this temporary workaround can be reverted. If we leave this issue as it is, me and other users of www/firefox are forced to do all kinds of extra work to get firefox working. PS. My solution was to simply compile and install alsa-plugins with BUFSZ_P2 option, which causes negative side effects in other apps. I will try compiling www/firefox with PULSEAUDIO and see how well that works. But I would prefer not having to depend on PULSEAUDIO, I consider it a cancer to be avoided.
A commit references this bug: Author: jbeich Date: Wed Mar 2 22:48:45 UTC 2016 New revision: 409976 URL: https://svnweb.freebsd.org/changeset/ports/409976 Log: audio/alsa-plugins: partially revert r380063 Restore BUFSZ_P2=on by default as a temporarily fix for excessive CPU usage in Firefox. r378529 wasn't enough to make BUFSZ_P2=off transition smooth. PR: 203732 Reported by: Henry Hu, Arto Pekkanen, many more indirectly MFH: 2015Q1 Changes: head/UPDATING head/audio/alsa-plugins/Makefile
A commit references this bug: Author: jbeich Date: Thu Mar 3 00:08:23 UTC 2016 New revision: 409992 URL: https://svnweb.freebsd.org/changeset/ports/409992 Log: MFH: r409976 audio/alsa-plugins: partially revert r380063 Restore BUFSZ_P2=on by default as a temporarily fix for excessive CPU usage in Firefox. r378529 wasn't enough to make BUFSZ_P2=off transition smooth. PR: 203732 Reported by: Henry Hu, Arto Pekkanen, many more indirectly Approved by: ports-secteam (feld) Changes: _U branches/2016Q1/ branches/2016Q1/UPDATING branches/2016Q1/audio/alsa-plugins/Makefile
(In reply to commit-hook from comment #4) Cool. I'll upgrade my system soon and test Firefox.
(In reply to commit-hook from comment #4) I have now updated all packages, including alsa-plugins. Firefox uses Pulseaudio as audio output. Firefox uses ~150% CPU (cpu usage via top, raw momentary cpu %, not weighted) when playing the following video from Youtube on 720p: https://www.youtube.com/watch?v=Eho8HDtkCiU My laptop has 2.6 Ghz i5 processor and Intel HD4000 GPU, so I think my hardware should definitely be on par with the task of playing the above video on 720p, and the CPU usage should not got above 100% ... I will try compiling/installing Firefox without Pulseaudio, and see if I get any better results.
(In reply to commit-hook from comment #4) Okay, now played the above Youtube test video with Firefox without Pulseaudio. CPU usage (top, raw cpu %) went down a bit, from 150% to around 100%, but CPU usage is still high. I've also discovered the problem is not only in the audio, problem also with video. You see, when I play video via Firefox, X.org uses around 50% CPU. This means that there is a LOT of data copying going on between Firefox and X.org. Honestly, the only way I could get X.org use more than a few percent of CPU during video playback with any media player is to use the obsolete X11 -backend (which apparently copies data and does other horrible things).
(In reply to Arto Pekkanen from comment #8) > ... when I play video via Firefox, X.org uses around 50% CPU. This means that there is a LOT of data copying going on between Firefox and X.org. What window resolution, video resolution, whether fullscreen or not? Better open a new bug and try various rendering toggles: - run a compositing manager (e.g., x11-wm/compton) - x11 driver (i915 vs. generic kms vs. vesa) or its options - gfx.xrender.enabled -> false - gfx.canvas.azure.backends -> skia - gfx.content.azure.backends -> skia (maybe buggy) - layers.offmainthreadcomposition.enabled -> false - layers.acceleration.force-enabled -> true (uses OpenGL) - BUNDLED_CAIRO -> off - GTK2 vs. GTK3 Firefox doesn't offload video decoding/scaling via VAAPI/XVideo unlike mpv/mplayer yet. However, OpenGL layers are scaled on hardware if available.
(In reply to Jan Beich from comment #9) I will try what you suggested. I've not used a compositor, because the SNA acceleration in Xorg configuration provides a working VSync (whereas the other acceleration methods would incur tearing in video playback)- But I could try using compton, see if it helps. If Firefox uses OpenGL (via Cairo) during video playback, I am really curious why it makes X.org use 50% CPU ... very strange indeed.
(In reply to Arto Pekkanen from comment #10) Check this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=970308 A developer mentioned "My answer was in reference to Linux not having hardware acceleration at this stage" And "There is no hardware acceleration on Linux at this stage. See bug 1210726. (and fwiw, at this stage no web browsers provide hardware accelerated video decoding)." https://bugzilla.mozilla.org/show_bug.cgi?id=1210726 It seems like that decoding with hardware is easier to support/is working, but rendering is harder.
(In reply to Jan Beich from comment #9) Hey I figured out why X.org uses so much CPU %. It is because of the XRender extension. If I disable XRender, then Firefox would use more CPU whilst X.org would use less. Apparently XRender is used to do basic compositioning at X-server end, and in my situation turning it off solved some of the excessive CPU usage.
(In reply to Arto Pekkanen from comment #12) You can go to about:config and turn gfx.xrender.enabled to off to see if it makes a difference. There are some plans to turn it off by default.
(In reply to Arto Pekkanen from comment #12) > If I disable XRender, then Firefox would use more CPU whilst X.org would use less. XRender can be disabled just for web content but not compositing: layers.use-image-offscreen-surfaces -> true (hidden pref). However, upstream disabled for both in Firefox 47. https://bugzilla.mozilla.org/show_bug.cgi?id=1180942#c17 https://bugzilla.mozilla.org/show_bug.cgi?id=1241832#c6
We hab version at 57.0.2. Is this still relevant?
(In reply to w.schwarzenfeld from comment #15) The original problem mentioned in the title is fixed. However, firefox still uses too much CPU in my opinion (~70% for the mentioned video). If I play the same video using mpv, it uses single digit percent. So this bug may still be relevant. On the other hand, this seems to be an upstream problem.
Thanks for quick reply.