Firefox drops ALSA

Message

Jaglover · Post by **Jaglover** » Thu Dec 15, 2016 11:29 pm

https://bugzilla.mozilla.org/show_bug.c ... 47056#c178

eccerr0r · Post by **eccerr0r** » Fri Dec 16, 2016 2:18 am

It didn't seem clear - PA required in the binary but you can build on your own, or completely dropped? Seems like the latter.

This will be annoying, I guess apulse may get some use...

Post by Hu » Fri Dec 16, 2016 2:23 am

That will suck. I don't play sound through Firefox, but as I read that ticket, their plan is to make Firefox fail to build if PulseAudio is not available. I guess once I get forced onto that release, I will get to spend time cleaning up their mess by adding always-fail stubs for the pulseaudio calls.

Jaglover · Post by **Jaglover** » Fri Dec 16, 2016 2:57 am

You do that.

And point us to the overlay with patches, you will make lots of folks happy here.

Anon-E-moose · Post by **Anon-E-moose** » Fri Dec 16, 2016 10:08 am

From the last comment

> $ firefox --version
> Mozilla Firefox 50.0
> $

ALSA support is dropped from Firefox 52 onward.

I wonder if they're shutting out oss4 also. I haven't used alsa in a long time. Plus I'm still using FF 38.
If they change things, then I suppose I'll go no further than FF 50 or I'll switch to chrome.
FF seems to be getting increasingly stupid in their old age.

Logicien · Post by **Logicien** » Fri Dec 16, 2016 10:36 am

Since Alsa drop it's Bluetooth support to the profit of Pulseaudio you can have sound without Alsa on Linux using Bluetooth headsets.

lost+found · Post by **lost+found** » Fri Dec 16, 2016 12:26 pm

Logicien wrote:Since Alsa drop it's Bluetooth support to the profit of Pulseaudio you can have sound without Alsa on Linux using Bluetooth headsets.

When I looked into it, it appeared to me that Bluez dropped unix socket support at some point, and as a result of that, Bluez also removed its Alsa plugin which depended on unix sockets.

Logicien · Post by **Logicien** » Fri Dec 16, 2016 1:21 pm

Yes lost+found,

this can explain why Alsa do not have Bluetooth support anymore and why Bluez do not have Alsa support anymore.

depontius · Post by **depontius** » Fri Dec 16, 2016 2:30 pm

I'm not sure about the whole thing here, but I run Skype using "apulse" instead of pulseaudio. I just checked, and pulseaudio is not a virtual that will accept either pulseaudio or apulse. This should be able to be handled with an apulse wrapper around firefox, but it may need a package.provided entry. Now I'm not sure if apulse provides everything necessary to replace pulseaudio for build purposes.

Pardon my rambling. I think this can be worked around, without resorting to an out-of-tree ebuild.

Logicien · Post by **Logicien** » Fri Dec 16, 2016 5:33 pm

I have never use apulse but, according to the package information, apulse depend on alsa-plugins who depend on Pulseaudio if using it's pulseaudio USE flag. I suppose using apulse will start Pulseaudio. Maybe Pulseaudio need to be configure to autospwan itself for apulse to work?

depontius · Post by **depontius** » Fri Dec 16, 2016 6:13 pm

I have apulse on a system that has never had pulseaudio installed on it. I just checked, and skype has both "apulse" and "pulseaudio" USE flags. Since skype is really a binary, there's nothing different about the code, the USE flags are just for tweaking dependencies, and for auto-creating an apulse wrapper, if needed.

I would suggest that even without an extra ebuild, pulseaudio could ba added to package.provided, and an apulse wrapper built.

mv · Post by mv » Fri Dec 16, 2016 6:58 pm

depontius wrote:I would suggest that even without an extra ebuild, pulseaudio could ba added to package.provided, and an apulse wrapper built.

The crucial question is whether firefox would be satisfied with the apulse shim libraries for building and running. If it is, it is just a question of writing an appropriate ebuild (which I hope the firefox maintainer of gentoo will do), and you can then either change with USE-flags or even at runtime when the ebuild is properly written. But again: The main question is whether the firefox code works out-of-the-box with the apulse shim.

eccerr0r · Post by **eccerr0r** » Fri Dec 16, 2016 7:03 pm

Perhaps there will be a virtual/pulseaudio that's satisfied by media-sound/pulseaudio or media-sound/apulse ...

I think the use flags for alsa/pulseaudio already is a confusing mess since pulseaudio requires alsa.

(Honestly despite having machines without PA, other than wasting more cycles to go through a userland application to process sound, PA has gotten quite a bit better. Having individual control of all sound clients pre mixer is very nice (so I can mute individual applications even if I can't find their own volume control!), not sure if there's this functionality with alsa directly.)

Jaglover · Post by **Jaglover** » Fri Dec 16, 2016 7:06 pm

PulseAudio may have its use, but for those who do not need PA it is just a parasite layer between ALSA and user application. We should have the choice.

mv · Post by mv » Fri Dec 16, 2016 7:46 pm

eccerr0r wrote:Perhaps there will be a virtual/pulseaudio that's satisfied by media-sound/pulseaudio or media-sound/apulse ...

A virtual makes only sense if there are a lot of consumers: If firefox is the only consumer of that virtual, one could omit the virtual and let firefox depend on "|| ( pulseaudio apulse )" instead - which is semantically equivalent but much simpler.
But both is only possible if apulse is really a drop-in replacement, i.e. if it can be exchanged also after firefox has been compiled with one of the two options; otherwise the information what is required must be stored in the system, i.e. a USE-flag is necessary to distinguish with what you want to compile firefox.

I think the use flags for alsa/pulseaudio already is a confusing mess since pulseaudio requires alsa.

I see nothing confusing here: Depending on the useflags, firefox talks with (and uses) either pulseaudio or with alsa. Whether some of the two then uses the other one to fulfill its task is a story which has nothing to do with firefox.

eccerr0r · Post by **eccerr0r** » Fri Dec 16, 2016 8:18 pm

mv wrote:I see nothing confusing here: Depending on the useflags, firefox talks with (and uses) either pulseaudio or with alsa. Whether some of the two then uses the other one to fulfill its task is a story which has nothing to do with firefox.

Yes, this is off topic as no, it's not a firefox issue - it's a general build issue. What's odd is that media-sound/pulseaudio has an alsa flag as itself uses alsa. So people would add USE=alsa to their world make.conf, and then all applications get USE=alsa when the user is actually using pulseaudio. (At least one person got caught up on this requirement and was having trouble building pulseaudio with -alsa.) Then having USE="alsa pulseaudio" all of the applications that support both would have redundant direct alsa support if they don't do per-package USE flag juggling.

depontius · Post by **depontius** » Fri Dec 16, 2016 10:28 pm

mv wrote:But both is only possible if apulse is really a drop-in replacement, i.e. if it can be exchanged also after firefox has been compiled with one of the two options; otherwise the information what is required must be stored in the system, i.e. a USE-flag is necessary to distinguish with what you want to compile firefox.

As I said, I'm using apulse with Skype, and that is precompiled. (OCO) I don't know if there's anything about firefox demanding more capability that Skype, but there is a binary-compatible existence theorem for at least one program.

mv · Post by mv » Sat Dec 17, 2016 4:01 am

depontius wrote:As I said, I'm using apulse with Skype, and that is precompiled.

In the case of Skype, I happen to know that it is not a drop-in replacement (that's why there is an apulse USE-flag in skype): There are special hacks by overriding library calls using LD_PRELOAD with a wrapper script. That's why I am afraid that future firefox might not compile with apulse at all without heavy patching.

mv · Post by mv » Sat Dec 17, 2016 4:19 am

eccerr0r wrote:What's odd is that media-sound/pulseaudio has an alsa flag as itself uses alsa.

If I recall correctly, it is the opposite here: The alsa USE-flag of pulseaudio causes an alsa-plugin to be built which causes "pure" alsa applications to pass control over to pulseaudio.

So people would add USE=alsa to their world make.conf

If they do this instead of using package.use when they want alsa for pulseaudio, they are doing something wrong. Moreover, pulseaudio has USE=+alsa enabled by default. Maybe one could improve documentation to make clearer that global USE-flags should be used only if one really wants global support for all applications, but I consider this a pure general documentation issue.

Then having USE="alsa pulseaudio" all of the applications that support both

Unless applications have the ability to configure the audio output at runtime (which will probably be the minority and which should be what the user wants if he enables both globally), either the ebuild ignores USE=alsa (perhaps printing a corresponding warning at build time) or the user will even get an explicit error due to REQUIRED_USE.

tld · Post by **tld** » Sat Dec 17, 2016 4:57 pm

This news especially sucks for me given that I'm forced to use firefox-bin on this (older) system. I doubt there will be any flexibility around that for firefox-bin. I really really wish I could come up with an alternative to firefox. It's a bloated piece of shit already and the mozilla devs are a bunch of self important a-holes as far as I can see. I hate it more and more every day, and this just gives me one more reason.