Re: Rationalising Linux audio backend support
Den fredag 31 mars 2017 kl. 15:49:50 UTC+2 skrev Chris Coulson: > On 31/03/17 05:52, burmar...@gmail.com wrote: > > Ubuntu just re-enabled ALSA on their latest Firefox 52.0.2 release. Go > > Ubuntu! > It's enabled, but please see the small-print in the changelog > description at > https://launchpad.net/ubuntu/+source/firefox/52.0.2+build1-0ubuntu0.16.04.1. > The Firefox package in Ubuntu is maintained by 1 contributor in his > spare time and myself who is only able to do the minimum in order to > provide updates, so Ubuntu flavors that don't ship Pulseaudio need to > step up to maintain this code if they want it to continue working and > don't want it to be disabled again in a future update. > On the other hand, Ubuntu is one of the most popular distros. So this action should push firefox in the right direction. Does anyone have an idea about the Debian policy? Fedora? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: realtime audio on linux
Den lördag 16 juli 2016 kl. 00:47:00 UTC+2 skrev Robert O'Callahan: > On Sat, Jul 16, 2016 at 5:09 AM, Steve Fink wrote: > > > I know it's kind of crazy given our garbage-collected, single content > > process world, but reading this thread makes me wonder what it would take > > to use the browser to implement a real linux-hosted audio workstation-type > > app. As in, something that requires truly low-latency audio with mixing. My > > (years stale) understanding is that pulseaudio is kind of the wrong model, > > and can't really offer the right guarantees at an architectural level. ALSA > > is, as ever, a mess, and just because you can play sound through ALSA on > > one hardware configuration doesn't really mean much for other drivers. > > > > Last I knew, JACK was the only way to get basically no dropouts and still > > be able to do nontrivial audio processing. But a JACK backend for the > > browser just seems kind of silly; it's too much of a niche "market" to try > > for anytime soon. > > > > A JACK backend for cubeb, hence Firefox, exists but isn't compiled into > Mozilla builds. > > The Web Audio API lets audio processing run on its own real-time thread, > and that's what Gecko does, although on Linux unprivileged users running > Firefox can't give that thread real-time priority. > > Rob > -- > lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf > toD > selthor stor edna siewaoeodm or v sstvr esBa kbvted,t > rdsme,aoreseoouoto > o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea > lurpr > .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr > esn Unless root has desired that they can. On ubuntu: /etc/security/limits.d/audio.conf. And users that uses JACK is member in the audio group. # Provided by the jackd package. # # Changes to this file will be preserved. # @audio - rtprio 95 @audio - memlockunlimited #@audio - nice -19 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
Den fredag 31 mars 2017 kl. 06:52:18 UTC+2 skrev burm...@gmail.com: > Ubuntu just re-enabled ALSA on their latest Firefox 52.0.2 release. Go Ubuntu! > > So thankfully I and many others can now forget about this sorry business. > > Martin Burke Good choice from Ubuntu. In the meantime, I have run PA->aloop->JACK. Now I am back with aloop->JACK. PA is removed from the system (and hopefully, I will never need it again). I turned on telemetry for now, but will turn it off when #1345661 has been resolved. As I said, the true solution for Firefox is to use PortAudio. No need for libcubeb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
Den torsdag 14 juli 2016 kl. 09:32:51 UTC+2 skrev Jet Villegas: > 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 > > There is no PulseAudio vs ALSA. There is only PulseAudio on top of ALSA. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
Den torsdag 14 juli 2016 kl. 04:31:50 UTC+2 skrev ajo...@mozilla.com: > 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. First, I want to bust these two myths about ALSA. ALSA is the kernel interface to the Linux audio subsystem. Thus, if ALSA cannot do stuff, no other library can either (unless it is a kernel module). 1. ALSA does not support full duplex: Wrong: Indeed, it does and JACK requires that feature. Otherwise, it cannot be used for step-by-step recording, and realtime DSP, which is the whole purpose of JACK. 2. ALSA does not support 5.1: Wrong: Connect your fat mixer console to the computer, start jack, and you will see a lot of inputs and outputs. Why because ALSA can record multichannel audio, and also play multichannel audio. To these two points I want to add that Intel PCH appears to not work in duplex mode on ALSA (and thus it would not work on PulseAudio either). But this is shitty hardware compared to the real stuff that were build in the 90:s (SoundBlaster AWE 64 gold with all connectors you would ever need: Line in, Line out, microphone in (+20 dB gain), and MIDI in/out. With right software, your home PC was a semi-professional grade music studio). As a second point, I would like to add a design guide, that should be considered before doing any audio programming: 1. There should be one and only one sound server running on the system 2. The sound server should *not* fiddle with sample rates, or anything else that requires conversion to frequency domain (such as 5.1 to various surround conversions). That should be done by the application internally, or through a library. The reason for this is that it adds latency that cannot be removed (unless you have a carefully calibrated flux capacitor constructed by Doc Brown :-P that pushes the signal back in time). And that boils down to the Heisenberg inequality. For those on this list that are more into computer graphics, the sample rate of the system should be treated as the refresh rate of the monitor. Do the display server convert the video
