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.

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

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

thanks!
--
waxmi...@gmail.com
waxm...@mail.ru
waxm...@bitrix24.com
0xC840F256B0F0FF9069E918d060063057AAaA6b36

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

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.

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.

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

On Thu, Jul 14, 2016 at 11:07 AM, Mike Hommey <m...@glandium.org> 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

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.

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

I know it's kind of crazy given our garbage-collected, single content
process world, but reading this thread makes me wonder what it would
take to use the browser to implement a real linux-hosted audio
workstation-type app. As in, something that requires truly low-latency
audio with mixing. My (years stale) understanding is that pulseaudio is
kind of the wrong model, and can't really offer the right guarantees at
an architectural level. ALSA is, as ever, a mess, and just because you
can play sound through ALSA on one hardware configuration doesn't really
mean much for other drivers.

Last I knew, JACK was the only way to get basically no dropouts and
still be able to do nontrivial audio processing. But a JACK backend for
the browser just seems kind of silly; it's too much of a niche "market"
to try for anytime soon.

Can anyone comment who is knowledgeable about audio and the state of
linux audio, unlike me? I'm curious how far off base I am. If I were to
try to do this today, I'd probably just use the browser to create the UI
and talk to a native app over a socket or ctypes or something.

On Sat, Jul 16, 2016 at 5:09 AM, Steve Fink <sf...@mozilla.com> wrote:

> I know it's kind of crazy given our garbage-collected, single content
> process world, but reading this thread makes me wonder what it would take
> to use the browser to implement a real linux-hosted audio workstation-type
> app. As in, something that requires truly low-latency audio with mixing. My
> (years stale) understanding is that pulseaudio is kind of the wrong model,
> and can't really offer the right guarantees at an architectural level. ALSA
> is, as ever, a mess, and just because you can play sound through ALSA on
> one hardware configuration doesn't really mean much for other drivers.
>
> Last I knew, JACK was the only way to get basically no dropouts and still
> be able to do nontrivial audio processing. But a JACK backend for the
> browser just seems kind of silly; it's too much of a niche "market" to try
> for anytime soon.
>

A JACK backend for cubeb, hence Firefox, exists but isn't compiled into
Mozilla builds.

The Web Audio API lets audio processing run on its own real-time thread,
and that's what Gecko does, although on Linux unprivileged users running
Firefox can't give that thread real-time priority.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

You've got great timing, support for --enable-jack just landed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ab76338931e

-Ted

On Fri, Jul 15, 2016 at 3:34 AM, Kurt Roeckx <ku...@roeckx.be> 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

>On 07/14/2016 05:36 PM, ajo...@mozilla.com wrote:

>Last I knew, JACK was the only way to get basically no dropouts and still
>be able to do nontrivial audio processing. But a JACK backend for the
>browser just seems kind of silly; it's too much of a niche "market" to try
>for anytime soon.

Likely so, though I'll note that Jack support for cubeb + Firefox has
recently been updated by a contributor; so you can build with a Jack
backend (or so I understand; I haven't tried it).

Padenot or achronop can tell you more about this.

--
Randell Jesup, Mozilla Corp
remove "news" for personal email

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

So this is were this idea started!
Great job guys, well, at least firefox is now unusable on Puppy Linux and low profile OSS.

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/

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!

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

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&id=0368ebdb85ec

--
Bug 1348576 is another example of relying on obscure options from CI.

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

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.

On Fri, Mar 24, 2017 at 11:45:57AM -0700, kthi...@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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

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

On Tue, Mar 28, 2017 at 6:49 PM,  <rec...@gmail.com> 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

On Tue, Mar 28, 2017 at 11:06 PM, Jan Beich <jbe...@freebsd.org> wrote:
> Botond Ballo <bot...@mozilla.com> 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

Den torsdag 14 juli 2016 kl. 04:31:50 UTC+2 skrev ajo...@mozilla.com:
> Supporting two separate audio backends in Linux is duplicated effort.
>

> I took over the platform media playback team at Mozilla a little over 3 years ago. At that point we only supported WebM/VP8/Vorbis, Ogg/Theora/Vorbis and Wave as well as MP3 on Windows and some additional codecs including MP4/H.264/AAC on a small number of Android phones. At that time most media in the browser ran in Flash.
>
> Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, HE-AAC, MSE and EME to our vocabulary. DASH and HLS are handled by site Javascript using MSE. A massive amount of effort has gone into making everything parallel so we can get as many pixels to the screen as possible. We’re working on platform specific performance improvements on Windows, Linux and Mac. We’re also doing some work to protect ourselves against driver crashes on Windows and Android.
>
> We are seeing an explosion of interest in HTML5 video and the accompanying audio is going through libcubeb, our audio backend. We’ve added low latency support to libcubeb for WebAudio and full duplex support so we can use it directly for microphone input for WebRTC.
>
> Our official Firefox builds on Linux support both PulseAudio and ALSA. There are a number of additional contributed backends that can be turned on at compile time, although contribution towards long-term maintenance and matching feature parity with the actively developed backends has been low. On Linux, we actively maintain the PulseAudio backend but we also approach the PulseAudio developers when we see issues in PulseAudio. The PulseAudio developers are generally good to work with.
>
> The most problematic backend across all platforms is ALSA. It is also missing full duplex support. We are intending to add multichannel (5.1) support across all platforms and the ones that don’t make the cut will be the ALSA backend and the WinMM backend used on Windows XP.
>
> Our ALSA backend has fallen behind in features, it is buggy and difficult to fix. PulseAudio is contrastingly low maintenance. I propose discontinuing support for ALSA in our official builds and moving it to off-by-default in our official builds.
>
> Leaving all the ALSA code in tree gives people the opportunity to continue maintaining the ALSA backend. Re-enabling it would require bringing it up to the same standard as other backends, not only in terms of current state but also in terms of consistency of contribution.
>
> As a long time Linux user, I want to get the most value out of our efforts on Linux. I can do that by focusing our efforts on the things that will have the greatest impact. Sometimes that requires taking a step back and deciding to do one thing well instead of two things poorly.

>
> Just to be clear, I’m proposing we stop spending time on ALSA so we can spend that time on adding 5.1 audio support to our PulseAudio backend.

First, I want to bust these two myths about ALSA. ALSA is the kernel interface to the Linux audio subsystem. Thus, if ALSA cannot do stuff, no other library can either (unless it is a kernel module).

1. ALSA does not support full duplex: Wrong: Indeed, it does and JACK requires that feature. Otherwise, it cannot be used for step-by-step recording, and realtime DSP, which is the whole purpose of JACK.

2. ALSA does not support 5.1: Wrong: Connect your fat mixer console to the computer, start jack, and you will see a lot of inputs and outputs. Why because ALSA can record multichannel audio, and also play multichannel audio.

To these two points I want to add that Intel PCH appears to not work in duplex mode on ALSA (and thus it would not work on PulseAudio either). But this is shitty hardware compared to the real stuff that were build in the 90:s (SoundBlaster AWE 64 gold with all connectors you would ever need: Line in, Line out, microphone in (+20 dB gain), and MIDI in/out. With right software, your home PC was a semi-professional grade music studio).


As a second point, I would like to add a design guide, that should be considered before doing any audio programming:

1. There should be one and only one sound server running on the system

2. The sound server should *not* fiddle with sample rates, or anything else that requires conversion to frequency domain (such as 5.1 to various surround conversions). That should be done by the application internally, or through a library. The reason for this is that it adds latency that cannot be removed (unless you have a carefully calibrated flux capacitor constructed by Doc Brown :-P that pushes the signal back in time). And that boils down to the Heisenberg inequality. For those on this list that are more into computer graphics, the sample rate of the system should be treated as the refresh rate of the monitor. Do the display server convert the video stream into a different framerate so it matches the refresh rate of the monitor?

3. Different applications has different latency requirements. The hardest requirements determine the sound server period. However, a short period will prevent CPU from going idle (not good for laptops on battery).


What does this imply?

1. Any application must be able to deal with any sound server that may be running on the given platform. If they have a very different API, consider using an external library, like PortAudio to hide their differences.

2. PulseAudio has severe design issues, so sometimes we have to use JACK. In this case PulesAudio is rejected in favour of JACK.

3. A sound server must have the options to configure its period. If the wall socket is unplugged, it may be necessary for it to restart with a longer period.


Conclusion: Before you dropped ALSA support, you should have implemented robust support for both PulseAudio, and JACK.

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

> > _______________________________________________
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

There is no PulseAudio vs ALSA. There is only PulseAudio on top of ALSA.

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

On Wed, Mar 29, 2017 at 12:29 PM, Kurt Roeckx <ku...@roeckx.be> 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
hsiv...@hsivonen.fi
https://hsivonen.fi/

Botond Ballo <bot...@mozilla.com> 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.

Henri Sivonen <hsiv...@hsivonen.fi> 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.

On Wed, Mar 29, 2017 at 3:40 AM, Henri Sivonen <hsiv...@hsivonen.fi> 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

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.

Den lördag 16 juli 2016 kl. 00:47:00 UTC+2 skrev Robert O'Callahan:
> On Sat, Jul 16, 2016 at 5:09 AM, Steve Fink <sf...@mozilla.com> wrote:
>
> > I know it's kind of crazy given our garbage-collected, single content
> > process world, but reading this thread makes me wonder what it would take
> > to use the browser to implement a real linux-hosted audio workstation-type
> > app. As in, something that requires truly low-latency audio with mixing. My
> > (years stale) understanding is that pulseaudio is kind of the wrong model,
> > and can't really offer the right guarantees at an architectural level. ALSA
> > is, as ever, a mess, and just because you can play sound through ALSA on
> > one hardware configuration doesn't really mean much for other drivers.
> >
> > Last I knew, JACK was the only way to get basically no dropouts and still
> > be able to do nontrivial audio processing. But a JACK backend for the
> > browser just seems kind of silly; it's too much of a niche "market" to try
> > for anytime soon.
> >
>
> A JACK backend for cubeb, hence Firefox, exists but isn't compiled into
> Mozilla builds.
>
> The Web Audio API lets audio processing run on its own real-time thread,
> and that's what Gecko does, although on Linux unprivileged users running
> Firefox can't give that thread real-time priority.

>
> Rob
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn

Unless root has desired that they can. On ubuntu: /etc/security/limits.d/audio.conf. And users that uses JACK is member in the audio group.

# Provided by the jackd package.
#
# Changes to this file will be preserved.
#

@audio   -  rtprio     95
@audio   -  memlock    unlimited
#@audio   -  nice      -19

On 31/03/17 05:52, burm...@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

Den fredag 31 mars 2017 kl. 15:49:50 UTC+2 skrev Chris Coulson:
> On 31/03/17 05:52, burm...@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?

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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1285195>.
Arch Linux now sends Telemetry
<https://bugzilla.mozilla.org/show_bug.cgi?id=1285201>.

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
<https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=Telemetry>,
mail to me or fhr-dev, or catch us on IRC in #telemetry.

Thanks,
Georg

On Fri, Mar 31, 2017 at 3:49 PM, Chris Coulson
<chris....@canonical.com> 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?

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.

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.

On Mar 31, 2017 4:49 PM, "Chris Coulson" <chris....@canonical.com>

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

I don't have the answer to that right now.

- Chris

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

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

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.

On 05.08.2017 07:27, kich...@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

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

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