Re: Rationalising Linux audio backend support
On Thursday, 23 March 2017 17:42:02 UTC+13, jtkel...@gmail.com wrote: > On Wednesday, March 22, 2017 at 1:35:06 PM UTC-5, Botond Ballo wrote: > > Based on this new information, might there be room to reconsider this > > decision? > > Even if you do not reconsider the full decision, could you at least turn it > back on for v52, so it can ride the ESR train? This has also been mentioned > in the bug in question. That would mean having to support ALSA until the ESR expires. > This would give users a longer period of time to try and transition to > PulseAudio or find a solution like apulse to keep Firefox audio working for > them. And it would give you more time to accept patches on the ALSA backend, > without impeding work on the 5.1 audio support for PulseAudio. > > Users would have to consciously choose to use the ESR version once v53 comes > out, hence you will be sure that they will be aware of the potential dropping > of ALSA support. > > It seems a simple fix to give the disgruntled users something and ease > hostilities, making things easier on all the devs involved, and give the > users a feeling that Mozilla listens, so they won't have another reason to > leave. The problem with re-enabling ALSA is that people will get the impression that we're still actively maintaining it. We're no longer maintaining the ALSA backend. > Clearly a lot of people are affected. A lot of smaller distros use Firefox as > their default, and do not want to include PulseAudio which adds a further > complication and is unnecessary for nearly every other Linux app. The maintenance cost of the ALSA backend in Firefox has an externality to these distributions. They can just use --enable-alsa and maintain the ALSA backend themselves. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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
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
Rationalising Linux audio backend support
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
