Re: Rationalising Linux audio backend support
On Friday, 15 July 2016 00:16:07 UTC+8, Georg Fritzsche wrote: > This gives an overview of the current incoming Telemetry for Linux (from a > 1% sample of our data, "canonical" is the Ubuntu distribution): > https://sql.telemetry.mozilla.org/queries/678#table > Also keep in mind, unless using opt-out probes, that the opt-in rates for > Telemetry are low: > https://sql.telemetry.mozilla.org/queries/682#table Most of the major distros use Pulse Audio so they can add Pulse Audio as a package dependency. Our official builds are in a different bucket so we're better to use the update ping to get data from them. Distros can still ship with ALSA support but they will need to take on the burden of making sure it works. There may be value in that for distros that are specific to a single piece of hardware. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
mozilla::NotNull
Hi, mozilla::NotNull is a recent addition to MFBT. It is used to mark pointers (both raw and smart) that are never null, e.g.: - NotNull - NotNull> - NotNull> It's most useful when used in function parameters and class members, more so than local variables. Its use can clarify APIs, and also help identify missing null checks and unnecessary null checks. See the comments in mfbt/NotNull.h for more details. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Reducing the NVIDIA Blacklist
Hello Mozillians, We recently relaxed our graphics blocklist for users with NVIDIA hardware using certain older graphics drivers. The original blocklist entry blocked all versions less than v8.17.11.8265 due to stability issues with NVIDIA 182.65 and earlier. We recently learned however that the first two numbers in the version string indicate platform version and the latter numbers refer to the actual driver version. As a result we were inadvertently blocking newer drivers on older platforms. We have since opened up the blacklist for versions newer than 8.15.11.8265 (Win XP) and 8.16.11.8265 (Vista/Win7) via https://bugzil.la/1284322, effectively drivers released beyond mid-2009.This change only exists on Nightly currently but we expect it to ride the trains unless some critical regression is discovered. If you are triaging bugs and user feedback, or are engaging with users on social media, please keep an eye out for users with NVIDIA hardware. If the user does have NVIDIA hardware please have them check the Graphics section of about:support to confirm if they are using a driver version that was previously blocked. If they are try to help them get updated to the most recent driver version. If the issue persists, have them disable hardware acceleration to see if the issue goes away. The same goes if you are a user experiencing quality issues (crashes, hangs, black screening, checkerboarding, etc) on NVIDIA hardware with these drivers. Please make sure your drivers are up to date. In either case, if the issue persists please file a bug via https://mzl.la/2a1qfUX so we can investigate what is happening. Feel free to email me if you have any questions. Thank you for your help! -- Anthony Hughes Sr. QA Engineer, Platform GFX Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DXR: All the things at 1pm Pacific, on Airmo from Mountain View
Hello! I'm Peter, returned from last summer to continue working on DXR. As my internship draws to a close, I would like to give a 10-minute overview on what's happened in DXR this summer and a tour of what's coming next. Teaser of "what's next": - search suggestions (complete as you type), - XBL methods search, - description column like MXR's, ...and other things! It's 1pm Pacific time, today, streamed and recorded on air.mozilla.org from Mountain View. Peter ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
On Thu, Jul 14, 2016 at 11:07 AM, Mike Hommey wrote: > On Thu, Jul 14, 2016 at 10:33:17AM +0200, Paul Adenot wrote: > > I just landed some telemetry to measure the usage of all audio backends, > > we'll have data soon. > > Usual question when it comes to Linux: what's the status of telemetry in > Distro builds? > This is a good point. We worked with Ubuntu to make sure that we are receiving Telemetry from there, but for other distributions it is not very clear. This gives an overview of the current incoming Telemetry for Linux (from a 1% sample of our data, "canonical" is the Ubuntu distribution): https://sql.telemetry.mozilla.org/queries/678#table Also keep in mind, unless using opt-out probes, that the opt-in rates for Telemetry are low: https://sql.telemetry.mozilla.org/queries/682#table Georg ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
On 2016-07-13 10:31 PM, ajo...@mozilla.com wrote: Our official Firefox builds on Linux support both PulseAudio and ALSA. There are a number of additional contributed backends that can be turned on at compile time, although contribution towards long-term maintenance and matching feature parity with the actively developed backends has been low. On Linux, we actively maintain the PulseAudio backend but we also approach the PulseAudio developers when we see issues in PulseAudio. The PulseAudio developers are generally good to work with. FWIW all of Arch, Fedora, Debian (including Raspian), (U/Ku/Xu)buntu, Mint, OpenSUSE ship PulseAudio by default, and have for a long time. You've got to work pretty hard to find a desktop linux distribution that doesn't; even Gentoo and Android-x86 have it reliably available. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
On Thursday, 14 July 2016 21:07:54 UTC+12, Mike Hommey wrote: > As for the proposal itself, as I said in some bug, I think it would be > better if, even if alsa is not supported, pulse was still optional. No > pulse would mean no sound, instead of ... Firefox not starting at all, > with probably no error message if it's launched through an icon. I don't want to break Firefox but I equally don't want it to continue to be unreliable. It pains me to say this, but rolling Pulse Audio into Firefox would fix the issue. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
On Thursday, 14 July 2016 19:32:51 UTC+12, Jet Villegas wrote: > A quick search for "ALSA vs. PulseAudio" comes up with mixed reviews for > either, which probably explains why we have both. It also seems like we can > count on ALSA being available on every distro, but perhaps not PulseAudio. Most abstraction layers that we've tried to use have been more trouble than they are worth. GStreamer is one such example. However Pulse Audio has proven to be an exception in that it protects us from the idiosyncrasies of ALSA. I prefer to focus our efforts on Pulse Audio to make it better because it benefits more than just Firefox. Not only that, we get good support from Pulse Audio so it is one of the easiest backends to maintain. ALSA is on the problematic end of the maintenance scale. > Can we add some telemetry to measure that? We could use telemetry but I'm confident enough to think that it is worth changing the update ping to include the Pulse Audio version. We already include the kernel and GTK versions. Those numbers can inform our deployment plan. > Alternatively, you can wire this up so that we only fall back to ALSA > (stereo) when we can't get PCM audio to route through Pulse. We can do that for the WinMM backend for Windows XP because it doesn't have the same kind of maintenance burden. It doesn't make sense for ALSA. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
On Thu, Jul 14, 2016 at 10:33:17AM +0200, Paul Adenot wrote: > I just landed some telemetry to measure the usage of all audio backends, > we'll have data soon. Usual question when it comes to Linux: what's the status of telemetry in Distro builds? As for the proposal itself, as I said in some bug, I think it would be better if, even if alsa is not supported, pulse was still optional. No pulse would mean no sound, instead of ... Firefox not starting at all, with probably no error message if it's launched through an icon. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
thanks! On 14/07/2016, Paul Adenot wrote: > I just landed some telemetry to measure the usage of all audio backends, > we'll have data soon. > > This was bug 1280630, and the probe is at [0]. This also measures > failures to open a stream and usage of backends that should not be used > on certain platform, like winmm on windows vista+. > > Also I support this proposal. > > Cheers, > Paul. > > [0]: > http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json#105 > > On Thu, Jul 14, 2016, at 09:32 AM, Jet Villegas wrote: >> I generally support reducing the support matrix for Linux PCM audio. >> >> A quick search for "ALSA vs. PulseAudio" comes up with mixed reviews for >> either, which probably explains why we have both. It also seems like we >> can >> count on ALSA being available on every distro, but perhaps not >> PulseAudio. >> Can we add some telemetry to measure that? >> >> Alternatively, you can wire this up so that we only fall back to ALSA >> (stereo) when we can't get PCM audio to route through Pulse. >> >> --Jet >> >> On Wed, Jul 13, 2016 at 7:31 PM, wrote: >> >> > Supporting two separate audio backends in Linux is duplicated effort. >> > >> > I took over the platform media playback team at Mozilla a little over 3 >> > years ago. At that point we only supported WebM/VP8/Vorbis, >> > Ogg/Theora/Vorbis and Wave as well as MP3 on Windows and some additional >> > codecs including MP4/H.264/AAC on a small number of Android phones. At >> > that >> > time most media in the browser ran in Flash. >> > >> > Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, >> > HE-AAC, >> > MSE and EME to our vocabulary. DASH and HLS are handled by site >> > Javascript >> > using MSE. A massive amount of effort has gone into making everything >> > parallel so we can get as many pixels to the screen as possible. We’re >> > working on platform specific performance improvements on Windows, Linux >> > and >> > Mac. We’re also doing some work to protect ourselves against driver >> > crashes >> > on Windows and Android. >> > >> > We are seeing an explosion of interest in HTML5 video and the >> > accompanying >> > audio is going through libcubeb, our audio backend. We’ve added low >> > latency >> > support to libcubeb for WebAudio and full duplex support so we can use >> > it >> > directly for microphone input for WebRTC. >> > >> > Our official Firefox builds on Linux support both PulseAudio and ALSA. >> > There are a number of additional contributed backends that can be turned >> > on >> > at compile time, although contribution towards long-term maintenance and >> > matching feature parity with the actively developed backends has been >> > low. >> > On Linux, we actively maintain the PulseAudio backend but we also >> > approach >> > the PulseAudio developers when we see issues in PulseAudio. The >> > PulseAudio >> > developers are generally good to work with. >> > >> > The most problematic backend across all platforms is ALSA. It is also >> > missing full duplex support. We are intending to add multichannel (5.1) >> > support across all platforms and the ones that don’t make the cut will >> > be >> > the ALSA backend and the WinMM backend used on Windows XP. >> > >> > Our ALSA backend has fallen behind in features, it is buggy and >> > difficult >> > to fix. PulseAudio is contrastingly low maintenance. I propose >> > discontinuing support for ALSA in our official builds and moving it to >> > off-by-default in our official builds. >> > >> > Leaving all the ALSA code in tree gives people the opportunity to >> > continue >> > maintaining the ALSA backend. Re-enabling it would require bringing it >> > up >> > to the same standard as other backends, not only in terms of current >> > state >> > but also in terms of consistency of contribution. >> > >> > As a long time Linux user, I want to get the most value out of our >> > efforts >> > on Linux. I can do that by focusing our efforts on the things that will >> > have the greatest impact. Sometimes that requires taking a step back and >> > deciding to do one thing well instead of two things poorly. >> > >> > Just to be clear, I’m proposing we stop spending time on ALSA so we can >> > spend that time on adding 5.1 audio support to our PulseAudio backend. >> > ___ >> > dev-platform mailing list >> > dev-platform@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-platform >> > >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- waxmigs2...@gmail.com waxmig...@mail.ru waxmig...@bitrix24.com 0xC840F256B0F0FF9069E918d060063057AAaA6b36 ___ dev-platform mailing list dev-p
Re: Rationalising Linux audio backend support
I just landed some telemetry to measure the usage of all audio backends, we'll have data soon. This was bug 1280630, and the probe is at [0]. This also measures failures to open a stream and usage of backends that should not be used on certain platform, like winmm on windows vista+. Also I support this proposal. Cheers, Paul. [0]: http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json#105 On Thu, Jul 14, 2016, at 09:32 AM, Jet Villegas wrote: > I generally support reducing the support matrix for Linux PCM audio. > > A quick search for "ALSA vs. PulseAudio" comes up with mixed reviews for > either, which probably explains why we have both. It also seems like we > can > count on ALSA being available on every distro, but perhaps not > PulseAudio. > Can we add some telemetry to measure that? > > Alternatively, you can wire this up so that we only fall back to ALSA > (stereo) when we can't get PCM audio to route through Pulse. > > --Jet > > On Wed, Jul 13, 2016 at 7:31 PM, wrote: > > > Supporting two separate audio backends in Linux is duplicated effort. > > > > I took over the platform media playback team at Mozilla a little over 3 > > years ago. At that point we only supported WebM/VP8/Vorbis, > > Ogg/Theora/Vorbis and Wave as well as MP3 on Windows and some additional > > codecs including MP4/H.264/AAC on a small number of Android phones. At that > > time most media in the browser ran in Flash. > > > > Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, HE-AAC, > > MSE and EME to our vocabulary. DASH and HLS are handled by site Javascript > > using MSE. A massive amount of effort has gone into making everything > > parallel so we can get as many pixels to the screen as possible. We’re > > working on platform specific performance improvements on Windows, Linux and > > Mac. We’re also doing some work to protect ourselves against driver crashes > > on Windows and Android. > > > > We are seeing an explosion of interest in HTML5 video and the accompanying > > audio is going through libcubeb, our audio backend. We’ve added low latency > > support to libcubeb for WebAudio and full duplex support so we can use it > > directly for microphone input for WebRTC. > > > > Our official Firefox builds on Linux support both PulseAudio and ALSA. > > There are a number of additional contributed backends that can be turned on > > at compile time, although contribution towards long-term maintenance and > > matching feature parity with the actively developed backends has been low. > > On Linux, we actively maintain the PulseAudio backend but we also approach > > the PulseAudio developers when we see issues in PulseAudio. The PulseAudio > > developers are generally good to work with. > > > > The most problematic backend across all platforms is ALSA. It is also > > missing full duplex support. We are intending to add multichannel (5.1) > > support across all platforms and the ones that don’t make the cut will be > > the ALSA backend and the WinMM backend used on Windows XP. > > > > Our ALSA backend has fallen behind in features, it is buggy and difficult > > to fix. PulseAudio is contrastingly low maintenance. I propose > > discontinuing support for ALSA in our official builds and moving it to > > off-by-default in our official builds. > > > > Leaving all the ALSA code in tree gives people the opportunity to continue > > maintaining the ALSA backend. Re-enabling it would require bringing it up > > to the same standard as other backends, not only in terms of current state > > but also in terms of consistency of contribution. > > > > As a long time Linux user, I want to get the most value out of our efforts > > on Linux. I can do that by focusing our efforts on the things that will > > have the greatest impact. Sometimes that requires taking a step back and > > deciding to do one thing well instead of two things poorly. > > > > Just to be clear, I’m proposing we stop spending time on ALSA so we can > > spend that time on adding 5.1 audio support to our PulseAudio backend. > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
I generally support reducing the support matrix for Linux PCM audio. A quick search for "ALSA vs. PulseAudio" comes up with mixed reviews for either, which probably explains why we have both. It also seems like we can count on ALSA being available on every distro, but perhaps not PulseAudio. Can we add some telemetry to measure that? Alternatively, you can wire this up so that we only fall back to ALSA (stereo) when we can't get PCM audio to route through Pulse. --Jet On Wed, Jul 13, 2016 at 7:31 PM, wrote: > Supporting two separate audio backends in Linux is duplicated effort. > > I took over the platform media playback team at Mozilla a little over 3 > years ago. At that point we only supported WebM/VP8/Vorbis, > Ogg/Theora/Vorbis and Wave as well as MP3 on Windows and some additional > codecs including MP4/H.264/AAC on a small number of Android phones. At that > time most media in the browser ran in Flash. > > Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, HE-AAC, > MSE and EME to our vocabulary. DASH and HLS are handled by site Javascript > using MSE. A massive amount of effort has gone into making everything > parallel so we can get as many pixels to the screen as possible. We’re > working on platform specific performance improvements on Windows, Linux and > Mac. We’re also doing some work to protect ourselves against driver crashes > on Windows and Android. > > We are seeing an explosion of interest in HTML5 video and the accompanying > audio is going through libcubeb, our audio backend. We’ve added low latency > support to libcubeb for WebAudio and full duplex support so we can use it > directly for microphone input for WebRTC. > > Our official Firefox builds on Linux support both PulseAudio and ALSA. > There are a number of additional contributed backends that can be turned on > at compile time, although contribution towards long-term maintenance and > matching feature parity with the actively developed backends has been low. > On Linux, we actively maintain the PulseAudio backend but we also approach > the PulseAudio developers when we see issues in PulseAudio. The PulseAudio > developers are generally good to work with. > > The most problematic backend across all platforms is ALSA. It is also > missing full duplex support. We are intending to add multichannel (5.1) > support across all platforms and the ones that don’t make the cut will be > the ALSA backend and the WinMM backend used on Windows XP. > > Our ALSA backend has fallen behind in features, it is buggy and difficult > to fix. PulseAudio is contrastingly low maintenance. I propose > discontinuing support for ALSA in our official builds and moving it to > off-by-default in our official builds. > > Leaving all the ALSA code in tree gives people the opportunity to continue > maintaining the ALSA backend. Re-enabling it would require bringing it up > to the same standard as other backends, not only in terms of current state > but also in terms of consistency of contribution. > > As a long time Linux user, I want to get the most value out of our efforts > on Linux. I can do that by focusing our efforts on the things that will > have the greatest impact. Sometimes that requires taking a step back and > deciding to do one thing well instead of two things poorly. > > Just to be clear, I’m proposing we stop spending time on ALSA so we can > spend that time on adding 5.1 audio support to our PulseAudio backend. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
