Re: Rationalising Linux audio backend support

2019-03-14 Thread darry19662015
On Thursday, July 14, 2016 at 2:31:50 PM UTC+12, Anthony Jones 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.




Could you please tell why it could not have possible to make it easy
to change the default reliance on Pulseaudio in these later versions
of Firefox to using the Alsa sound system instead?

I use Puppy Linux and it uses Alsa by default which works well on my
system where as pulse audio doesn't and I cannot understand why when
the change was made in Firefox to using Pulseaudio that there could
not have been a simple option in about:config to switch to Alsa?
Firefox is suppposed to be Free-Software as in Freedom - so why was my
freedom to choose taken away?  This has done users of Firefox a great
disservice.

Therefore I request that in future versions of Firefox that this
option please be added,

Yours Sincerely


Darren Hale
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2018-11-24 Thread Boris Zbarsky

On 11/24/18 6:35 AM, susa...@gmail.com wrote:

It is strange to hear "we are misserable impotent at ALSA" from Mozilla devs...

Well, anyway, 2 years after your decision - how is feeling each time alsa-only 
user courses you? Enjoy!


I'm sorry to have to say this, but the post above fails to observe the 
"be respectful" and "no personal attacks" guidelines.  Please see 
https://www.mozilla.org/en-US/about/governance/policies/participation/ 
for more details.  Please comply with those in the future if you decide 
to post here.


If you have a specific argument you want to make about resource 
allocation, please feel free to do so.  Such arguments should probably 
be accompanied by either new factual information that was not considered 
when making the existing allocation decisions or by an argument that 
priorities should now be different from what they were then.  All this 
can and should be done without being rude to people.


Thank you,
Boris.

P.S.  Same thing in Russian, just to make sure we're on the same page:

К сожалению ваш пост не следует принципам "будь почтительным" и "не 
нападай на людей" из 
. 
 В будущем, пожалуйста следуйте этим принципам.


Если вы хотите оспорить принятое решение о распререлении ресурсов, 
пожалуйста, оспаривайте.  Для этого нужно либо предоставить новые факты 
которые не были учтены при принятии решения либо аргументировать, что 
приоритеты изменились или должны измениться.  Все это можно и нужно 
сделать в вежливой форме.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2018-11-24 Thread susanin
четверг, 14 июля 2016 г., 5:31:50 UTC+3 пользователь Anthony Jones написал:
> 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.

It is strange to hear "we are misserable impotent at ALSA" from Mozilla devs...

Well, anyway, 2 years after your decision - how is feeling each time alsa-only 
user courses you? Enjoy!

...

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-10-04 Thread Enrico Weigelt, metux IT consult

On 29.09.2017 19:26, t...@tomsbox.co.uk wrote:

As someone who has had wonderful times with ALSA & headaches with PA it's time 
to say goodbye FireFox.


Maybe we should have a closer look at the PA library API, whether it
could be usable w/o the pa daemon. IOW: have libpulse implementations
that directly call the native APIs (eg. ALSA on Linux or directsound
on windows).

Another idea could be creating a *thin* (!) API layer, that bridges
to backends of the operator's choice. This, of course, should be 
independent of moz and in plain C, so it can be used by many other

projects having the same problem, instead of yet another private layer.


--mtx

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-09-29 Thread tom
As someone who has had wonderful times with ALSA & headaches with PA it's time 
to say goodbye FireFox.
FireFox was my first goto browser for years now I'll add it to my purge script 
just under pulseaudio.

Expecting users to give up 2 hours & 15Gb just to get alsa support in a browser 
is tbf pointless, enjoy your reduced size market share.

Farewell Dev's and thanks for all the code of yours I put to great use over the 
years.

Bye,
Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-08-05 Thread Enrico Weigelt, metux IT consult

On 05.08.2017 07:27, kichu...@gmail.com wrote:

Hi folks,


You're right. I have a sound card that supports mixing and all other necessary 
stuff in hardware, why shoud I waste my CPU for doing that with pulseaudio?
Long time ago I switched from Opera to Firefox... maybe it's time to switch 
back.


haven't followed the whole thread, but let me add a few thoughts:

Few month ago I had a discussion w/ PA folks about non-Linux platforms.
It seems that it works well on win32, mac, bsd, etc (not tested
myself).

So, why not just using libpulse directly (w/o any extra layers) ?
Folks who don't wanna have the PA daemon in between could patch up
libpulse to talk to the actual device directly.

That way, we'd have moved out all the platform specific logic to an
already widely adopted subsystem and therefore less own code to
maintain.


--mtx

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-08-05 Thread kichusek
W dniu czwartek, 13 kwietnia 2017 10:58:05 UTC+2 użytkownik 
daniel@freepascal.org napisał:
> Therefore if you can't maintain ALSA support, as I see it, you are doing a 
> poor job support Linux. The ALSA API isn't rocket science either, so if 
> attempt to look at it from a developer point of view, I don't see much hassle 
> as well.

You're right. I have a sound card that supports mixing and all other necessary 
stuff in hardware, why shoud I waste my CPU for doing that with pulseaudio?
Long time ago I switched from Opera to Firefox... maybe it's time to switch 
back.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-06-13 Thread wrzlbrmbft559
I know, it's a pretty late answer but:

My four Computers, running on Linux (OpenSuSE) are working fine with alsa from 
the beginning of alsa on. Now there is no need for a unneccessary intermediate 
layer named Pulseaudio in an fine working alsa-system. Numberless Tux-Users 
ignore pulse and pulse still doesn't had it's breakthrough till now...

Since Firefox doesn't support alsa, i use at the moment seamonkey or palemoon. 
If they go the same way, there will be other browsers, who respect the users 
and do not ignore them. Bye Firefox.

I use Tux since 2002 and i know, what i am writing about.

Bye
Michael
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-04-13 Thread daniel . mantione
A message from a poor duped user here:

I have 4 computers, only 1 runs Pulseaudio. Pulseaudio simply doesn't work or 
work well on 2 of them and the third running bare Alsa have a Sound Blaster 
Audigy with hardware mixing that would be abstracted away by Pulseaudio, so 
Pulseaudio is undesired here.

I read the comments about Alsa being unmaintained. The way I see it from an 
user point of view:
- ALSA is the official Linux audio API
- Pulseaudio is a popular, but optional, add-on package
- An application supporting ALSA works on all systems, including systems with 
Pulseaudio
- An application supporting Pulseaudio only works with Pulseaudio

Therefore if you can't maintain ALSA support, as I see it, you are doing a poor 
job support Linux. The ALSA API isn't rocket science either, so if attempt to 
look at it from a developer point of view, I don't see much hassle as well.

Best regards,

Daniël Mantione
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-04-05 Thread Chris Coulson

On 05/04/17 19:38, Henri Sivonen wrote:
> On Mar 31, 2017 4:49 PM, "Chris Coulson" 
> wrote:
>
> 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,
>
>
> Does today’s announcement of Ubuntu’s change in direction affect resourcing
> for Firefox packaging?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
I don't have the answer to that right now.

- Chris



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-04-05 Thread Henri Sivonen
On Mar 31, 2017 4:49 PM, "Chris Coulson" 
wrote:

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,


Does today’s announcement of Ubuntu’s change in direction affect resourcing
for Firefox packaging?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-04-03 Thread ajones
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

2017-04-03 Thread doncuppjr
I want to say thank you for all the wonderful work that the Mozilla team does 
to create this product. Fantastic. I am equally impressed that you took the 
time to ask some basic questions like "what percentage of our Linux users are 
using ALSA vs Pulse". That was very courteous, but I don't think it comes from 
an understanding of how Linux is used in some very common deployment 
scenario's. 

It might happen from time to time that a new user starts their digital life on 
the Linux platform, but I would bet that most users are migrants. A new user 
might click through dialogs and accept defaults, including telling others about 
what he does, but a regular Linux user is little more paranoid. The 
administrators of such systems would be very adept and likely arrived at Linux 
as a solution for it's scalability. Now when we talk about things that scale, 
we are usually talking about huge numbers, in the thousands and tens of 
thousands. Organizations with those kinds of numbers don't usually like be 
counted, and so the very adept admins( the biggest distributors of linux ) will 
disable telemetry as a part of their deployment process. Check SALT, Chef, 
Puppet, CF Engine and so on.

In short, by relying on telemetry to determine what Linux users do or have, you 
have likely limited your perspective to the newest, least knowledgable and most 
likely to leave users available on the platform.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-04-03 Thread Jean-Yves Avenard
On Fri, Mar 31, 2017 at 3:49 PM, Chris Coulson
 wrote:
> 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.

Sorry for hijacking.

But ubuntu's firefox build doesn't enable rust.

A side effect is that FLAC support (and other codecs in MP4)  isn't
enabled as a consequence.

Any chances to get that enabled?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-04-03 Thread Georg Fritzsche
Given Ubuntus popularity, we decided to first reach out to that
distribution.
With limited resources and other work, we haven't reached out much further
yet.

Recently, there was some progress:
Fedora is apparently submitting Telemetry
.
Arch Linux now sends Telemetry
.

However, we do depend on work from the distributions.
If you want to work with us on this, please reach out by filing a bug
,
mail to me or fhr-dev, or catch us on IRC in #telemetry.

Thanks,
Georg

On Sat, Apr 1, 2017 at 2:48 PM,  wrote:

> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-04-01 Thread milasudril
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: Rationalising Linux audio backend support

2017-03-31 Thread 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.

Regards
- Chris
> So thankfully I and many others can now forget about this sorry business.
>
> Martin Burke
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-31 Thread Robert O'Callahan
On Fri, Mar 31, 2017 at 7:45 PM,   wrote:
> 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.

We looked at PortAudio a long time ago and it had major problems.
Apparently it still did as of 2014:
http://camlorn.net/posts/december2014/horror-of-audio-output.html

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-31 Thread milasudril
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

2017-03-30 Thread burmartke
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-29 Thread Ralph Giles
On Wed, Mar 29, 2017 at 3:40 AM, Henri Sivonen  wrote:

> Arguably, system configuration info belongs under FHR, so it would not
> be optimal if the Pulse check wasn't there but was in opt-in Telemetry
> instead. Where was it?

The check was marked opt-out.

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json#154
https://bugzilla.mozilla.org/show_bug.cgi?id=1280630

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-29 Thread Jan Beich
Henri Sivonen  writes:

> It's a problem if distros disable FHR by default

Probably a regression from bug 722240. Did Mozilla contact downstream
maintainers they now have to explicitly opt-in? Bug 1233687 suggests the
answer is "no", favoring one distro over the others.

> or if distros disable the first-run on-boarding UI for opt-in Telemetry.

See bug 667577.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-29 Thread Jan Beich
Botond Ballo  writes:

> Anyways, there is no conflict between supporting ALSA and supporting
> 5.1 sound. As has been mentioned earlier in the thread, ALSA has since
> added support for 5.1, and so IIUC it's just our wrapper library
> (libcubeb) that needs the support added.

When did this happen? Bug 1341108 still stands. Try building without
PulseAudio then set media.forcestereo.enabled -> false in about:config.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-29 Thread Henri Sivonen
On Wed, Mar 29, 2017 at 12:29 PM, Kurt Roeckx  wrote:
> The FAQ seems to suggest that telemetry is only enabled in the pre-release 
> versions
> and not in the release versions. I assume there is a bias that is caused by 
> this.

There are two types of telemetry: "Firefox Health Report" (enabled by
default) and "Telemetry" (enabled by default in Nightly, Aurora and
Beta but not in release builds).

Arguably, system configuration info belongs under FHR, so it would not
be optimal if the Pulse check wasn't there but was in opt-in Telemetry
instead. Where was it?

It's a problem if distros disable FHR by default or if distros disable
the first-run on-boarding UI for opt-in Telemetry.

In any case, running without telemetry means not having a say in
data-driven decisions about what configurations Mozilla should
support. It's OK to disable telemetry (that's why it's
user-controllable), but both users and distros that make decisions on
users' behalf should to take into account that if don't let Firefox
send info about your system config to Mozilla, your system config is
invisible to Mozilla's decision making about what to support.

> Pulseaudio is really a layer between the application and alsa. If pulseaudio
> can do something it should be possible to do the same with alsa.

It's not that "ALSA can't do this or that" it's "cubeb on top of ALSA
without Pulse in between can't do this or that without additional work
that's already done by Pulse or by cubeb on top of Pulse".

> But maybe pulseaudio makes certain things easier, I don't know.

That PulseAudio makes things easier has been a key point that has been made.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-29 Thread Kurt Roeckx

On 2017-03-22 19:34, Botond Ballo wrote:

Now that this change has hit the release channel, we've started
receiving feedback from a wider range of users, a lot of it in bug
1345661 [1].

I believe the feedback in that thread brings some new information to
the table that we weren't aware of when this decision was made:

  - Based on the volume of the feedback we received, and the number
of duplicate bugs and so on, it appears that quoted telemetry data
underestimates the number of users who use ALSA. This is
corroborated by the fact that some of the affected distributions
disable telemetry in their Firefox packages.


I was under the impression that the telemetry said it was over 1%. If 
all of those start to report that it's broken, you will get a lot of 
reports. I also thinking breaking more than 1% of the users setup is way 
too high.


I've also reported that certain desktop environments don't come with 
pulseaudio by default.


The FAQ seems to suggest that telemetry is only enabled in the 
pre-release versions and not in the release versions. I assume there is 
a bias that is caused by this.



  - A number of users, particularly those in the audiophile and music
production / recording communities, report technical reasons for
preferring ALSA over PulseAudio.

  - We've had an offer from someone to volunteer to maintain the
ALSA backend (bug 1345661 comment 52 [2]).


Pulseaudio is really a layer between the application and alsa. If 
pulseaudio can do something it should be possible to do the same with 
alsa. But maybe pulseaudio makes certain things easier, I don't know.


In any case, alsa is supported on any linux version, while it's clear 
that for various reasons pulseaudio is not. It makes sense to me to 
support alsa, and maybe only alsa. As I understand it, if you only 
support alsa and the user is using pulseaudio you still end up using 
pulseaudio.



Kurt

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-29 Thread milasudril
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

2017-03-29 Thread milasudril
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 

Re: Rationalising Linux audio backend support

2017-03-28 Thread Botond Ballo
On Tue, Mar 28, 2017 at 11:06 PM, Jan Beich  wrote:
> Botond Ballo  writes:
>
>> Anyways, there is no conflict between supporting ALSA and supporting
>> 5.1 sound. As has been mentioned earlier in the thread, ALSA has since
>> added support for 5.1, and so IIUC it's just our wrapper library
>> (libcubeb) that needs the support added.
>
> When did this happen?

I was going off of statements made in bug 1345661, such as in comment
63: "ALSA supports 5.1 audio perfectly well; I'm using it daily." [1],
and a quick Google search suggests ALSA supports 5.1 audio as well.

> Bug 1341108 still stands.

It looks like that bug concerns 5.1 support in the libcubeb ALSA
backend, not in ALSA itself.

Cheers,
Botond

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345661#c63
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-28 Thread Botond Ballo
On Tue, Mar 28, 2017 at 6:49 PM,   wrote:
> Why does a  BROWSER need 5.1 or x.y sound???

The web platform is intended to be a competitive alternative to native
platforms. That means that whatever native applications can do, we'd
like web applications to be able to do as well, and that includes
playing 5.1 sound.

As an (important) example, I imagine there is a growing segment of
users who watch T.V. shows and movies through a computer running
Netflix in a browser, and some of those users want the browser to be
able to play 5.1 sound.

Anyways, there is no conflict between supporting ALSA and supporting
5.1 sound. As has been mentioned earlier in the thread, ALSA has since
added support for 5.1, and so IIUC it's just our wrapper library
(libcubeb) that needs the support added.

> and remove your spying telemetry too

First, I don't see how collecting aggregate technical statistics like
what fraction of our Linux users use PulseAudio and what fraction use
ALSA, is a threat to anyone's privacy or otherwise constitutes
"spying".

Second, continuing to opt out of telemetry will just make problems
like this worse. As was stated in this thread, one of the
justifications for removing ALSA support was that the telemetry
numbers showed a very little ALSA usage. If more ALSA users had
telemetry enabled, perhaps the outcome would have been different.

Cheers,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-28 Thread rec9140
On Wednesday, July 13, 2016 at 10:31:50 PM UTC-4, ajo...@mozilla.com wrote:
> Supporting two separate audio backends in Linux is duplicated effort.

Then support, ONE.. ALSA.

> The most problematic backend across all platforms is ALSA. It is also missing 
> full duplex support.

Don't disagree... BUT... I use ALSA features that are a must... several 
features of ALSA actually eliminate PHYSICAL HARDWARE in my use..


>We are intending to add multichannel (5.1)

Why does a  BROWSER need 5.1 or x.y sound??? Its a browser!!! If you need that 
kind of audio playback, then the browser regardless of which one is NOT the 
software to use! XBMC, OpenElec or various other media playback setups would be 
a much better solution than a browser.

> 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.

x.y audio is the basis factor to determine if ALSA is continued??? Again, WHY 
do you need x.y audio in a BROWSER There is suitable video/audio players 
for that, and a browser is not it!

I don't use pulseaudio... one of the first things I do on new installs and for 
the images I use ENTERPRISE WIDE is to remove pulseaudio... until recently 
guess what else was removed?? FIREFOX! We only added it to kill a support 
nightmare with Konqueror since its render engine doesn't keep up... And with 
this decision, I am again, will be REMOVING FIREFOX from our image and 
demoviting from our repo mirrors

My entrerpise is a large level install. I don't speak for them publically so I 
can't name them or elaborate, but suffice it to say, thats a lot of users that 
won't be using firefox in the near future, and its a lot grief for me to purge 
it away.

Why don't I use pulseaudio?? As I stated I use ALSA plugins which are required 
to do my daily tasks, PA interferes with those.. plus its just plain buggy.. 
pops, crackles, and glitches in audio from any software that plays audio... 
ALSA just works, never had an issue with it. NEVER in 20+ years of Linux use. 
The biggest hurdle is the documentation for its features...but that applies to 
a lot of software. 

Additionally with systemd's arrival from the same author that just enforces why 
I don't use pulseaudio! Not interested in that thing either!

So lets be clear...

If --enable-alsa and that will allow distros to put back, AND mozillas future 
updates to go down the PA route don't break adding ALSA back then I will get 
*buntu/Debian enforce that in their bulds and remove your spying telemetry too. 
(Which definitely means we need to be looking at our firewall logs to ensure 
this gets turned off!)

All this blow up to have x.y audio in a browser??? Really???

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-28 Thread Anthony Jones

On 22/03/2017 2:34 PM, Botond Ballo wrote:

Now that this change has hit the release channel, we've started
receiving feedback from a wider range of users, a lot of it in bug
1345661 [1].

I believe the feedback in that thread brings some new information to
the table that we weren't aware of when this decision was made:

   - Based on the volume of the feedback we received, and the number
 of duplicate bugs and so on, it appears that quoted telemetry data
 underestimates the number of users who use ALSA. This is
 corroborated by the fact that some of the affected distributions
 disable telemetry in their Firefox packages.
This is anecdotal so it is hard to evaluate. Distributions can re-enable 
ALSA and telemetry in the short term. If they are significant then our 
numbers will move.

   - A number of users, particularly those in the audiophile and music
 production / recording communities, report technical reasons for
 preferring ALSA over PulseAudio.

They will need to create/use tier-3 builds.

   - We've had an offer from someone to volunteer to maintain the
 ALSA backend (bug 1345661 comment 52 [2]).
We will continue to accept community contributions. However we won't be 
re-enabling ALSA until we've established a longer term pattern of 
support. The outstanding work includes sandboxing support, 5.1 and bug 
fixes.

Based on this new information, might there be room to reconsider this decision?

No. It is now too late.

Anthony
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-24 Thread Trevor Saunders
On Fri, Mar 24, 2017 at 11:45:57AM -0700, kthies...@mozilla.com wrote:
> On Wednesday, March 22, 2017 at 9:42:02 PM UTC-7, 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. 
> > 
> > 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. 
> > 
> > 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.
> 
> Agreed.  PulseAudio is "opinionated software," much like systemd, by the same 
> author.  Some folks feel that PulseAudio's opinions, like systemd's, run 
> counter to the practices of good Linux/Unix system operators.  Insisting on 
> PulseAudio discourages the inclusion of Firefox in the smaller, less 
> commercially-focused distros.

Speaking only for myself even leaving asside my opinions about
PulseAudio's opinions its opinions can come into conflict with other
software that people care about more than audio.  That happens for me
personally, and while I still use Firefox I've accepted not having audio
in the browser.

Trev

> 
> Also, please be aware that this will have effects on *BSD ports of Firefox.  
> Most of the people who run BSD by choice want nothing to do with "Linuxisms" 
> like PulseAudio.
> 
> Thanks for reading,
> --KT.
> 
> --
> Karl THIESSEN
> Systems group, Firefox Test Engineering,
> Mozilla Corp.
> ___
> 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

2017-03-24 Thread kthiessen
On Wednesday, March 22, 2017 at 9:42:02 PM UTC-7, 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. 
> 
> 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. 
> 
> 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.

Agreed.  PulseAudio is "opinionated software," much like systemd, by the same 
author.  Some folks feel that PulseAudio's opinions, like systemd's, run 
counter to the practices of good Linux/Unix system operators.  Insisting on 
PulseAudio discourages the inclusion of Firefox in the smaller, less 
commercially-focused distros.

Also, please be aware that this will have effects on *BSD ports of Firefox.  
Most of the people who run BSD by choice want nothing to do with "Linuxisms" 
like PulseAudio.

Thanks for reading,
--KT.

--
Karl THIESSEN
Systems group, Firefox Test Engineering,
Mozilla Corp.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-23 Thread jeanchristophecesttropcourt
Le mercredi 15 mars 2017 02:24:57 UTC+1, qiana...@gmail.com a écrit :
> Am Mittwoch, 15. März 2017 00:11:24 UTC+1 schrieb gfra...@gmail.com:
> > So this is were this idea started!
> > Great job guys, well, at least firefox is now unusable on Puppy Linux and 
> > low profile OSS.
> 
> yes, indeed: :(
> 
> - A developer who don't like work much on ALSA and chose the easy way!
> (Hey, you are working for one of the famoust browsers in the world! You have 
> no ressources for this???)
> 
> - the decision to make a 5.1, DRM, AmazonPrime, commercial video on 
> demand-multimediacenter compatible Multimediacenter as a browser
> 
> - not recognizing how much Linux-Distros, projects and users prefer ALSA 
> without Pulseaudio for several reasoons!
> 
> - ignoring that ALSA is the soundbase in every Linux since more than 10y
> and PA is just a sound-server!
> 
> - not informing the community to have this design-break early, so that they 
> can decide and react and don't have distros/systems with broken sound with 
> one ff-update in browser and a lot of work too!
> 
> - basing on telemetry that is sayin`nothing!!!
> most users i know don't use telemetry in their browsers!
> Pure-ALSA-users are knowing as people who love FREEDOM much! ;-)
> 
> And at the end some devs that explain that they are not uptodate with 
> Linux-Sound-base!???
> 
> Hey c'mon: this is really how you decided this?
> 
> i can't believe.
> 
> Rollback to ALSA as the only main soundriver and soundsystem in Linux, maybe 
> make Jack optional running too (it has a lot of potential) and maybe support 
> pulseaudio too - but please let the people choose!!!
> 
> I read in your group here that it was implemented before, that firefox DONT 
> require PA as a hard dependency and that ff was using ALSA if PA was not 
> found on system!
> 
> THIS could be the best SOULution with your next build of FF!
> 
> And a big note in www that you support ALSA again!
> 
> It's no option to say that the people can recompile their alsa-based ff by 
> theirself! I tried this one night with Linux Mint 17.3 and gcc 4.9 - but it 
> was a mess! A lot of people are running away from ff now after years.
> 
> It happens right now!
> 
> maybe this are some hundreds or thousands - but hey: it does matter how you 
> treat your users!
> 
> So all i want is constractive and to motivate you:
> 
> Please be patient!
> 
> it's no fun for many people to have breaking sound with Linux Firefox, 
> because of an  update and without a note before.
> 
> Respect this please.
> 
> If you need more people working on ALSA with Firefox - get them on board!
> 
> You are Mozilla!
> 
> And hey: Where is the problem? firefox was building with ALSA for many years 
> and it don't has to be so much work to implement 5.1 and fullduplex (use dmix 
> or other options!) and keep it rolling.
> 
> If you want to see Firefox 52 working on our little A/V-Distro - that is 
> stable and just released in January and basing on Ubuntu 14.04, Linux Mint 
> 17.3 and KXStudio - as a typical scene what happens on a typical ALSA-based 
> Linux system that prefers to have FF as the default browser!
> 
> http://mayastudio.tumblr.com/64bit
> 
> http://qianastudio.tumblr.com
> 
> That we now have to rebuild again with maybe another browser is just one 
> example for what can happen, if you don't communicate breaks like this with 
> the Linux Community.
> 
> So i hope you will find a way and thinking about the fact, that there are 
> many advanced Linux-users outside (without telemetry) that prefers ALSA 
> without PA and that they love Firefox (too).
> 
> Maybe the (sometimes harsh) feedback from your bugzilla will open your eyes!? 
> ;-) https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
> 
> It's emotional. This is a fact (too).
> 
> but a problem to solve also...
> 
> If you just keep on stopping supporting ALSA than it has to be so.
> 
> There are alternative browsers. 
> 
> But i can't understand: BECAUSE Pulseaudio is setting upon ALSA and works NOT 
> without ALSA! So ALSA is the (kernel-)sounddriver in every Linux-System and 
> Pulseaudio just a server as a routing-backend!
> 
> If the soundcard is not configured right and recognized by kernel and it's 
> modules- than the soundcard DONT works with PA too!
> 
> So you just have to arrange with ALSA and maybe it helps you, if you contact 
> some devs there!??:
> 
> Maybe they could help you same way like PA-devs do!??
> 
> I don't know - but it could be an option!#
> 
> best regards,
> 
> chalee, Phil and kAte
> 
> http://alsa.opensrc.org/

Could not agree more. I WONT use pulseaudio. So if firefox will, I wont use it, 
despite all its qualities.

Open your eyes. Don't let me use Chromium.

Regards
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-23 Thread Jan Beich
Botond Ballo writes:

> Now that this change has hit the release channel, we've started
> receiving feedback from a wider range of users, a lot of it in bug
> 1345661 [1].
>
> I believe the feedback in that thread brings some new information to
> the table that we weren't aware of when this decision was made:
>
>   - Based on the volume of the feedback we received, and the number
> of duplicate bugs and so on, it appears that quoted telemetry data
> underestimates the number of users who use ALSA. This is
> corroborated by the fact that some of the affected distributions
> disable telemetry in their Firefox packages.

Telemetry is actually disabled by default but Mozilla CI opts in for all
of its mozconfigs. Downstream may simply be unaware but use their own
builds to tweak options (e.g. --prefix, --with-system-*, --enable-alsa)
and/or apply patches. A year ago Ubuntu enabled telemetry but other
distributions started to follow the suit only recently.

https://bugzilla.mozilla.org/show_bug.cgi?id=1233687#c5
http://pkgs.fedoraproject.org/cgit/rpms/firefox.git/commit/?id=b2b845f7ba35
https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/firefox=0368ebdb85ec

--
Bug 1348576 is another example of relying on obscure options from CI.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-22 Thread jtkelley52
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. 

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. 

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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-22 Thread Botond Ballo
Now that this change has hit the release channel, we've started
receiving feedback from a wider range of users, a lot of it in bug
1345661 [1].

I believe the feedback in that thread brings some new information to
the table that we weren't aware of when this decision was made:

  - Based on the volume of the feedback we received, and the number
of duplicate bugs and so on, it appears that quoted telemetry data
underestimates the number of users who use ALSA. This is
corroborated by the fact that some of the affected distributions
disable telemetry in their Firefox packages.

  - A number of users, particularly those in the audiophile and music
production / recording communities, report technical reasons for
preferring ALSA over PulseAudio.

  - We've had an offer from someone to volunteer to maintain the
ALSA backend (bug 1345661 comment 52 [2]).

Based on this new information, might there be room to reconsider this decision?

Cheers,
Botond

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1345661#c52

On Thu, Aug 25, 2016 at 8:56 AM, Randell Jesup  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.
>
> We have some data now; in Aurora 50 it's 96.5%/3.5%, Nightly 51 is
> 98%/2%
>
> Of course, even Aurora users aren't necessarily "typical" users, but I
> imagine these will not move much in the favor of Alsa in Beta or
> release, and more likely move towards Pulse ("users" are more likely to
> be running plain-jane distros which have Pulse enabled by default - but
> we'll see).
>
> We'll start getting beta results in a few weeks.
>
> --
> Randell Jesup, Mozilla Corp
> remove "news" for personal email
> ___
> 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

2017-03-14 Thread qianastudio
Am Montag, 18. Juli 2016 15:57:27 UTC+2 schrieb Ralph Giles:
> On Fri, Jul 15, 2016 at 3:34 AM, Kurt Roeckx  wrote:
> 
> > I also wonder how this fallback thing works.  Things are linked to the
> > pulseaudio library, but if the pulseaudio binary isn't installed things fall
> > back to something else like alsa as far as I know.  Is this something the
> > pulseaudio library does, or do you need to write the fallback yourself?
> 
> Currently, we try to dlopen the pulseaudio interface library and fall
> back to alsa if that fails. So it's a build-time dependency (for the
> headers) but not a run-time dependency. Except on gonk, where we
> assume it's available and link to it directly. See
> https://github.com/mozilla/gecko-dev/blob/378278ea830e7b01fb280d5274adccdfb2baab28/media/libcubeb/src/cubeb_pulse.c#L503
> 
>  -r

Contact the ALSA-devs: http://www.alsa-project.org/main/index.php/Main_Page

Let Firefox work on ALSA-based systems without PA too, please!

Thanx!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-14 Thread qianastudio
Am Mittwoch, 15. März 2017 00:11:24 UTC+1 schrieb gfra...@gmail.com:
> So this is were this idea started!
> Great job guys, well, at least firefox is now unusable on Puppy Linux and low 
> profile OSS.

yes, indeed: :(

- A developer who don't like work much on ALSA and chose the easy way!
(Hey, you are working for one of the famoust browsers in the world! You have no 
ressources for this???)

- the decision to make a 5.1, DRM, AmazonPrime, commercial video on 
demand-multimediacenter compatible Multimediacenter as a browser

- not recognizing how much Linux-Distros, projects and users prefer ALSA 
without Pulseaudio for several reasoons!

- ignoring that ALSA is the soundbase in every Linux since more than 10y
and PA is just a sound-server!

- not informing the community to have this design-break early, so that they can 
decide and react and don't have distros/systems with broken sound with one 
ff-update in browser and a lot of work too!

- basing on telemetry that is sayin`nothing!!!
most users i know don't use telemetry in their browsers!
Pure-ALSA-users are knowing as people who love FREEDOM much! ;-)

And at the end some devs that explain that they are not uptodate with 
Linux-Sound-base!???

Hey c'mon: this is really how you decided this?

i can't believe.

Rollback to ALSA as the only main soundriver and soundsystem in Linux, maybe 
make Jack optional running too (it has a lot of potential) and maybe support 
pulseaudio too - but please let the people choose!!!

I read in your group here that it was implemented before, that firefox DONT 
require PA as a hard dependency and that ff was using ALSA if PA was not found 
on system!

THIS could be the best SOULution with your next build of FF!

And a big note in www that you support ALSA again!

It's no option to say that the people can recompile their alsa-based ff by 
theirself! I tried this one night with Linux Mint 17.3 and gcc 4.9 - but it was 
a mess! A lot of people are running away from ff now after years.

It happens right now!

maybe this are some hundreds or thousands - but hey: it does matter how you 
treat your users!

So all i want is constractive and to motivate you:

Please be patient!

it's no fun for many people to have breaking sound with Linux Firefox, because 
of an  update and without a note before.

Respect this please.

If you need more people working on ALSA with Firefox - get them on board!

You are Mozilla!

And hey: Where is the problem? firefox was building with ALSA for many years 
and it don't has to be so much work to implement 5.1 and fullduplex (use dmix 
or other options!) and keep it rolling.

If you want to see Firefox 52 working on our little A/V-Distro - that is stable 
and just released in January and basing on Ubuntu 14.04, Linux Mint 17.3 and 
KXStudio - as a typical scene what happens on a typical ALSA-based Linux system 
that prefers to have FF as the default browser!

http://mayastudio.tumblr.com/64bit

http://qianastudio.tumblr.com

That we now have to rebuild again with maybe another browser is just one 
example for what can happen, if you don't communicate breaks like this with the 
Linux Community.

So i hope you will find a way and thinking about the fact, that there are many 
advanced Linux-users outside (without telemetry) that prefers ALSA without PA 
and that they love Firefox (too).

Maybe the (sometimes harsh) feedback from your bugzilla will open your eyes!? 
;-) https://bugzilla.mozilla.org/show_bug.cgi?id=1345661

It's emotional. This is a fact (too).

but a problem to solve also...

If you just keep on stopping supporting ALSA than it has to be so.

There are alternative browsers. 

But i can't understand: BECAUSE Pulseaudio is setting upon ALSA and works NOT 
without ALSA! So ALSA is the (kernel-)sounddriver in every Linux-System and 
Pulseaudio just a server as a routing-backend!

If the soundcard is not configured right and recognized by kernel and it's 
modules- than the soundcard DONT works with PA too!

So you just have to arrange with ALSA and maybe it helps you, if you contact 
some devs there!??:

Maybe they could help you same way like PA-devs do!??

I don't know - but it could be an option!#

best regards,

chalee, Phil and kAte

http://alsa.opensrc.org/









___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2017-03-14 Thread gfran1995
So this is were this idea started!
Great job guys, well, at least firefox is now unusable on Puppy Linux and low 
profile OSS.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2016-08-25 Thread Randell Jesup
>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. 

We have some data now; in Aurora 50 it's 96.5%/3.5%, Nightly 51 is
98%/2%

Of course, even Aurora users aren't necessarily "typical" users, but I
imagine these will not move much in the favor of Alsa in Beta or
release, and more likely move towards Pulse ("users" are more likely to
be running plain-jane distros which have Pulse enabled by default - but
we'll see).

We'll start getting beta results in a few weeks.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2016-07-18 Thread Ralph Giles
On Fri, Jul 15, 2016 at 3:34 AM, Kurt Roeckx  wrote:

> I also wonder how this fallback thing works.  Things are linked to the
> pulseaudio library, but if the pulseaudio binary isn't installed things fall
> back to something else like alsa as far as I know.  Is this something the
> pulseaudio library does, or do you need to write the fallback yourself?

Currently, we try to dlopen the pulseaudio interface library and fall
back to alsa if that fails. So it's a build-time dependency (for the
headers) but not a run-time dependency. Except on gonk, where we
assume it's available and link to it directly. See
https://github.com/mozilla/gecko-dev/blob/378278ea830e7b01fb280d5274adccdfb2baab28/media/libcubeb/src/cubeb_pulse.c#L503

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2016-07-15 Thread Kurt Roeckx

On 2016-07-14 17:49, Mike Hoye wrote:

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.


At least according to https://wiki.debian.org/PulseAudio, on Debian you 
don't get it by default when installing xfce or lxde.  But I guess you 
can argue what by default means.


I also wonder how this fallback thing works.  Things are linked to the 
pulseaudio library, but if the pulseaudio binary isn't installed things 
fall back to something else like alsa as far as I know.  Is this 
something the pulseaudio library does, or do you need to write the 
fallback yourself?



Kurt

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Rationalising Linux audio backend support

2016-07-14 Thread ajones
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

2016-07-14 Thread Georg Fritzsche
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

2016-07-14 Thread Mike Hoye

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

2016-07-14 Thread ajones
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

2016-07-14 Thread ajones
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

2016-07-14 Thread Mike Hommey
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

2016-07-14 Thread waxmiguel
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

Re: Rationalising Linux audio backend support

2016-07-14 Thread Paul Adenot
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

2016-07-14 Thread 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Rationalising Linux audio backend support

2016-07-13 Thread ajones
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