[Solved] Firefox support for ALSA audio _input_

[lars_the_bear]

Hi folks

I'm aware that Firefox doesn't want to support direct ALSA audio. But, building with "USE=alsa -pulsaudio..." does result in something that works -- at least for playback.

But I get no audio _input_ which, of course, is essential for Zoom, etc. It's not that I get an error message -- it's just as if the audio input is muted, or its recording from a different source.

I find that 'arecord xxx' works fine, either with the default device or if I set the specific ALSA device. I've gone to alsamixer and turned all the volume sliders up to maximum, but it makes no difference.

Given firefox's general lack of support for ALSA, I'm not entirely surprised that it doesn't work. But has anybody else tried it?

I thought I had identified all the show-stoppers that would prevent me adopting ALSA as my day-to-day platform, but I hadn't thought about this one. If I can't run Zoom, I've have to go back to Fedora :/

I'm willing to try a different browser but (for different reasons) neither Chromium nor Google Chome will install.

BR, Lars.

[RumpletonBongworth]

If I can't run Zoom, I've have to go back to Fedora :/

This seems illogical. It would work in Fedora because Fedora uses pipewire by default. You have the option of using pipewire in Gentoo. Anyway, running Firefox with apulse might help you.

[lars_the_bear]

This seems illogical. It would work in Fedora because Fedora uses pipewire by default. You have the option of using pipewire in Gentoo.

I have the option of using systemd and the Gnome desktop as well. But these are exactly the complexities that I hoped Gentoo would allow me to avoid.

I have absolutely no need for pipewire or pulse. Worse, running these things makes it harder to use ordinary ALSA effectively, because they tend to take control of the ALSA system for their own purposes. Every other piece of software I use that does audio, does it fine with plain ALSA. It's not Gentoo's fault that the Firefox maintainers can't be bothered to support ALSA properly, and I'm not wedded to Firefox. I'm happy to use something else.

It turns out that Google Chrome (the proprietary, binary version) works fine. I'm hoping that Chromium will also work fine, when it finishes building in about three weeks.

It's sad that Firefox has gone the way it has. I'll use a different browser, rather than trying to work around it.

BR, Lars.

[RumpletonBongworth]

I understand. Naturally, there's only so much a distributor can do. In your case, switching to a different browser is a valid choice and probably a sensible one given your intended constraints.

[lars_the_bear]

Naturally, there's only so much a distributor can do.

Yeah. I'm certainly not blaming Gentoo for this. I was hoping somebody had seen the same problem, and would say "Just click the 'use ALSA input button"

On PC-like platforms, it seems to me that FIrefox is the only thing that stands between Google and World domination. Chromium is still essentially controlled by Google. It would be nice if people had something to fall back on if Chrome/Chromium became completely unusable. So I'm saddened to find that I can't easily use Firefox as my only browser on my Gentoo systems.

BR, Lars.

[RumpletonBongworth]

Using the apulse wrapper is as close to clicking a button as it gets, I think. Certainly not as convenient.

[pjp]

I have absolutely no need for pipewire or pulse. Worse, running these things makes it harder to use ordinary ALSA effectively, because they tend to take control of the ALSA system for their own purposes. Every other piece of software I use that does audio, does it fine with plain ALSA. It's not Gentoo's fault that the Firefox maintainers can't be bothered to support ALSA properly, and I'm not wedded to Firefox. I'm happy to use something else.

So you know, I don't use systemd, pipewire or pulseaudio. Firefox will work with media-sound/apulse, which uses ALSA underneath:

The program provides an alternative partial implementation of the PulseAudio API. It consists of a loader script and a number of shared libraries with the same names as from original PulseAudio, so applications could dynamically load them and think they are talking to PulseAudio. Internally, no separate sound mixing daemon is used. Instead, apulse relies on ALSA's dmix, dsnoop, and plug plugins to handle multiple sound sources and capture streams running at the same time. dmix plugin muxes multiple playback streams; dsnoop plugin allow multiple applications to capture from a single microphone; and plug plugin transparently converts audio between various sample formats, sample rates and channel numbers. For more than a decade now, ALSA comes with these plugins enabled and configured by default.

apulse wasn't designed to be a drop-in replacement of PulseAudio. It's pointless, since that will be just reimplementation of original PulseAudio, with the same client-daemon architecture, required by the complete feature set. Instead, only parts of the API that are crucial to specific applications are implemented. That's why there is a loader script, named apulse. It updates value of LD_LIBRARY_PATH environment variable to point also to the directory where apulse's libraries are installed, making them available to the application.

Name comes from names of both ALSA and PulseAudio. As aoss was a compatibility layer between OSS programs and ALSA, apulse was designed to be compatibility layer between PulseAudio applications and ALSA.

If you were already aware of that, then carry on ;)

[Ralphred]

Using the apulse wrapper is as close to clicking a button as it gets, I think. Certainly not as convenient.

apluse always gave me static, especially with output and input in Firefox. It got to the point I just got bored with fixing things every time there was a regression.
My issues with pulseaudio are it's impermanence by default* and (at the time) it's inability to connect to alsa properly with, again, input and output.
If pulse works out of the box for you then that's great, but if you are left in the realm of crafting config files from it's shoddy documentation, it's a real PITA. This is a shame because if you disable all "magical autoconfig" and have a working static config with no bells and whistles (as well as have it made a "permanent service" on login) it actually behaves quite well, and the ubiquity of pulse support in software makes things "just work". You can even redirect things that want to talk directly to alsa to the pulseaudio daemon with alsa, so pulse is transparent to them.

*I still can't make pulse run as a "system wide daemon" (needed for multiseat in this case) even after reading all the docs, it just doesn't work as advertised. I'm still defaulting to running jackd in promiscuous mode and having each users own pulse daemon connect to that. I know it doesn't sound ideal, but has proven to be a really solid and relyable solution that's needed no "after set-up" tinkering for a long time now.

[lars_the_bear]

[quote="pjp"]Firefox will work with media-sound/apulse, which uses ALSA underneath: [quote]

Thanks. Can you confirm that it works with input, as well as output? I note other comments that aren't as positive as yours

Also: how does apulse cope when there are multiple PCM inputs and outputs?

While I like to avoid using Google stuff as much as possible, I have to admit that Chrome handled my situation pretty well. Although I have multiple source devices, only one has an input. Zoom used that one, and selected the output that goes with it, even though neither is a default device at the ALSA level.

BR, Lars.

[Ralphred]

Also: how does apulse cope when there are multiple PCM inputs and outputs?

It uses the default as defined by asoundrc.

Out of the box, and following most alsa related tutorials, the combination of capture and output into a single PCM is mostly ignored, but you need to combine your dsnoop and dmix as an async* PCM and set that as default.

*this is from memory, so that may be from me having more than one sound card at that time.

[pjp]

Thanks. Can you confirm that it works with input, as well as output? I note other comments that aren't as positive as yours ;)

I cannot. I only use it for the occasional video or playing music locally.

It does seem like anything advanced or involving multiple devices leads people to pipewire. A bit old, but from early in pipewire's existence:

Yeah for a simple single audio stream directly via alsa there is no point in adding extra layers.
With more involved setup like multiple audio streams playing simultaneously, you can use alsa "dmix"..

But for almost anything beyond that, like adding echo cancellation for mics, persisting volume adjustment per application, automatically moving your audio to AVR you seldom use - at present you want to use pulseaudio. Audio part of pipewire project is being actively evolved to be better pulseaudio in every aspect, and things like audio processing latency are already better, though not all replacement parts to make it usable on desktops are available right now.

[AJM]

*I still can't make pulse run as a "system wide daemon" (needed for multiseat in this case) even after reading all the docs, it just doesn't work as advertised.

This is either sad or hilarious, given that this was basically the thing that PulseAudio was claiming to provide in the first place (when it was a replacement for ESD.) I suppose PulseAudio was my first introduction to the world of Lennart Poettering's shoddy bloated lying software... promises galore, zero valid documentation, insane and utterly unmanageable configuration files and nothing ever working as advertised.

Anyway, to the original point... on my Gentoo PC I use firefox(-bin) with apulse and have just checked and confirmed that I can make a Zoom test call - definitely no PulseAudio here!

[lars_the_bear]

Anyway, to the original point... on my Gentoo PC I use firefox(-bin) with apulse and have just checked and confirmed that I can make a Zoom test call - definitely no PulseAudio here!

OK. Thank you. At present, I am able to use Zoom with Google Chrome and Chromium; but I'd rather use Firefox if I can.

Weirdly, with Chrome, Zoom allows me to select the input device so, presumably, it ignores defaults. But for output, it only uses the ALSA default. So I still have to hack on the ALSA config.

BR, Lars.

[lars_the_bear]

It does seem like anything advanced or involving multiple devices leads people to pipewire. A bit old, but from early in pipewire's existence

Yeah, I get it. I understand why pipewire/pulse exist. Both are fine, from an ease-of-use perspective. But so, frankly, is Windows.

But my real concern with pipewire/pulse is that they are so complicated, I can't begin to understand them. Heaven knows, ALSA is bad enough. But I've figured out (based on trial-and-error, rather than knowledge) how to set up ALSA so that I can send hi-res audio to my DAC without it being fiddled about with. I imagine the same is possible with pipewire/pulse, but I've never figured out how.

BR, Lars.

[Ralphred]

Anyway, to the original point... on my Gentoo PC I use firefox(-bin) with apulse and have just checked and confirmed that I can make a Zoom test call - definitely no PulseAudio here!

This is good news. Drop your asoundrc for Lars please, just in case.

But my real concern with pipewire/pulse is that they are so complicated, I can't begin to understand them.

Like I said, pulse is quite nice when you can rein it in and have it only do what you want, but by default it tries to be all things automatically, and because it succeeds at that for a lot of people documentation and examples are sparse. I know I'm going to possibly have to switch to pipewire someday, if/when I do I'll be bridling that to "do what you are told, nothing more!" too, at which point I'll try and drop some examples and explanations here in the forums.

[AJM]

The only config file I can find for anything ALSA related is /etc/asound.conf which simply contains the lines:

Code: Select all

defaults.pcm.!card Generic_1
defaults.pcm.!device 0
defaults.ctl.!card Generic_1

[saturnalia0]

firefox-bin works for me. I start it like so:

Code: Select all

 xhost si:localuser:ff && sudo -u ff apulse firefox-bin -P & exit

The relevant part for you is `apulse firefox-bin`. This is from media-sound/apulse.

I use ALSA only. Make sure you can record like so:

Code: Select all

arecord -f S16_LE test.wav
aplay test.wav

If you can't, open alsamixer from media-sound/alsa-utils, select the right sound card (F6), then select Caputre (F4), navigate with the right arrow to "Input source" and use the up/down arrows to select rear/front mic accordingly.

Once you can record with arecord it should work with firefox.

Then open a "mic test" website and it should work....

[Chiitoo]

Looking at the ebuilds, I believe www-client/firefox-bin already uses apulse by default, if USE="alsa -pulseaudio".

On the other hand, www-client/firefox always does so if USE="pulseaudio" and media-sound/apulse is installed; in this case the PulseAudio backend is enabled. With USE="-pulseaudio", the ALSA backend is enabled instead, in which case I imagine some web applications might require running Firefox through apulse manually.

[lars_the_bear]

Looking at the ebuilds, I believe www-client/firefox-bin already uses apulse by default, if USE="alsa -pulseaudio".

On the other hand, www-client/firefox always does so if USE="pulseaudio" and media-sound/apulse is installed; in this case the PulseAudio backend is enabled. With USE="-pulseaudio", the ALSA backend is enabled instead, in which case I imagine some web applications might require running Firefox through apulse manually.

I guess in both these cases apulse has to be installed, right? And maybe running?

I guess I might have to use apulse in the end. I've got nothing against it, except that it's another always-on process , sitting there eating memory. That's the kind of thing I want to avoid.

It's particular galling in this case because ALSA is easy to support, and exists (I think) on every Linux platform since about 2002. The use of apulse solves a problem that should simply not exist. Many Linux application still support OSS, for Heavens' sake, and that's not been in widespread use for at least 20 years. There's just no excuse for not supporting ALSA properly.

BR, Lars.

[Chiitoo]

Yeah, would need to have it installed, and the bin version will pull in media-sound/apulse as a dependency itself if the alsa USE-flag is enabled, but pulseaudio is not.

For the non-bin version, it's optional, so if you wanted to run with the ALSA backend, then you'd need to manually install apulse, with pulseaudio flag disabled on Firefox. The other option here is install media-sound/apulse manually before, or at the same time with Firefox, with the pulseaudio USE-flag enabled, which will make Firefox use the PulseAudio backend via apulse instead.

As for apulse itself, as far as I understand, it does not run as a process, but rather only provides libraries, a partial API, and a loader script.

All that said, I don't know that there is any harm in running the apulse script twice, that is, as many examples show 'apulse firefox-bin' where 'firefox-bin' itself will also run 'apulse', but of course what actually is going on depends on the USE-flags...

[lars_the_bear]

I built firefox with "USE=alsa -pulseaudio". So I presume that apulse won't work for me, because there's no pulse support in firefox to exercise it. (?)

When built this way, as I said, I get audio output via ALSA, but no input. Weirdly, firefox (with ALSA) does respect .soundrc for selecting an output device. The same settings should set the default input device -- at least 'arecord' says they do. But nothing from firefox.

IIUC, to use apulse I'd need to build firefox with pulse enabled, and not ALSA. Or I'd have to find a binary build, and tell emerge to ignore my USE=-pulseaudio(?)

But that would mean, I think, that I'd only be able to use it with apulse, right?

Right now, I'm sort-of resigned to having to use Chrome or Chromium for Zoom, etc. Even if apulse doesn't require extra processes, it's still a solution to a problem that should not exist.

BR, Lars.

[Chiitoo]

I built firefox with "USE=alsa -pulseaudio". So I presume that apulse won't work for me, because there's no pulse support in firefox to exercise it. (?)

That is a good question. I wonder what exactly Firefox does then...

If it still let's apulse to emulate PulseAudio to the application, I think it should work? My main use for apulse has been games that only support PulseAudio, giving no beep with plain ALSA, but running them via apulse would work, so in my mind it would be similar but, thinking about it now, I suppose it might not be... at all.

I'll need to try the compiled version at some point later. It's around 30°C here, and not really feeling like compiling clang and friends just to test this right now. ^^;

When built this way, as I said, I get audio output via ALSA, but no input. Weirdly, firefox (with ALSA) does respect .soundrc for selecting an output device. The same settings should set the default input device -- at least 'arecord' says they do. But nothing from firefox.

Yeah, I believe it should, too, and testing quickly with www-client/firefox-bin, I can change the capture device, which I know from the error messages being different.

That is, apulse seems to be pretty particular about devices, and I couldn't make it work yet. It keeps complaining about the device being in use, even if it's a microphone, being accessed directly, with nothing else using it.

Do you get any such messages in terminal when you try?

Considering the status of plain ALSA backend support in Firefox, I guess it could just be missing something to work there, without apulse.

IIUC, to use apulse I'd need to build firefox with pulse enabled, and not ALSA. Or I'd have to find a binary build, and tell emerge to ignore my USE=-pulseaudio(?)

As mentioned, not sure at this time how Firefox and web applications will behave in this case.

Regarding a binary build, don't need to look far, since there is www-client/firefox-bin, or do you mean something different?

But that would mean, I think, that I'd only be able to use it with apulse, right?

It will use apulse if installed, and libpulse if not.

Right now, I'm sort-of resigned to having to use Chrome or Chromium for Zoom, etc. Even if apulse doesn't require extra processes, it's still a solution to a problem that should not exist.

These web applications sure are too many fun, in too many fun ways...

[pjp]

Yeah, I get it. I understand why pipewire/pulse exist. Both are fine, from an ease-of-use perspective. But so, frankly, is Windows.

But my real concern with pipewire/pulse is that they are so complicated, I can't begin to understand them. Heaven knows, ALSA is bad enough. But I've figured out (based on trial-and-error, rather than knowledge) how to set up ALSA so that I can send hi-res audio to my DAC without it being fiddled about with. I imagine the same is possible with pipewire/pulse, but I've never figured out how.

BR, Lars.

Software changes. Your description of how ALSA is less complicated than it's presumptive successor(s) reminds me of when I avoided ALSA because it was needlessly complicated and OSS "just worked." At some point I switched and I don't do anything to it.

It's particular galling in this case because ALSA is easy to support, and exists (I think) on every Linux platform since about 2002. The use of apulse solves a problem that should simply not exist. Many Linux application still support OSS, for Heavens' sake, and that's not been in widespread use for at least 20 years. There's just no excuse for not supporting ALSA properly.

I may be mistaken, but I believe part of why pulse/pipe exist were due to limitations of ALSA. Particularly when trying to do more than one audio function at a time. From a development perspective, it makes a lot of sense (to me) that it would be easier to support only one of multiple solutions.

I'm just glad I don't have to switch to something I don't otherwise need.

[szatox]

Dunno, I'd say ALSA is a nighmare.
It was fine when there was only 1 audio device and used by default, but the way it's configured still sucks and getting anything non-standard is overly complicated, and I don't recall documentation being super useful either.

Which is why I really got to like jack when I switched, even though I don't do anything related to audio. The virtual patch bay is just a nice feature.
And now pipewire improves on that by allowing multiple audio devices, and wireplumber's policies add some convenience with automatic routing whenever new port is added to the canvas... And integration with easyeffects saves my ears from volume levels changing randomly from one recording to another (using compressor plugin just before playback device)
The software certainly is more complicated, but it also has a better user interface making it easier to configure and use. Just gotta get it to run as a system service instead of a per-user instances competing for hardware (one day, hopefully; when I'm not busy with other things).

[lars_the_bear]

I may be mistaken, but I believe part of why pulse/pipe exist were due to limitations of ALSA. Particularly when trying to do more than one audio function at a time. From a development perspective, it makes a lot of sense (to me) that it would be easier to support only one of multiple solutions.

I'm not saying there's never a need for Pulse, etc. I understand what these things set out to achieve. ALSA dates from a time when it was rare to have more than one sound device, and nobody expected multiple applications to play audio at the same time. ALSA can cope with these things now although, so far as I know, it still can't use separate audio channels for different applications, which means that you can't set their volume levels independently. And ALSA's configuration is byzantine and the documentation essentially non-existent. I've written applications that use it, and I still don't really understand it. And getting it to work with Bluetooth audio is horrible.

But, although I've used Pulse and PipeWire for many years on Fedora/Ununtu, I still don't understand them, either. They seem to me to take all the complexities of ALSA, and add some of their own. I still don't know, for example, how to get a 24bit/96kHz audio stream from Qobuz to my DAC, without it being downsampled by Pulse. I do know how to do that with ALSA.

As for application development, yeah, I fully understand why it's a drain on resources, to support multiple audio frameworks. But here's the thing: if you support ALSA, you support everything else as well, because there are ALSA plug-ins to adapt to everything else. So the audio stuff I wrote for ALSA works with Pulse and PipeWire as well, with no changes on my part. On my Fedora systems, the default ALSA device is actually a PipeWire plug-in, so I don't even have to select a particular ALSA device to play to.

Still, I'm not suggesting for a moment that anybody else should be compelled to use raw ALSA. It just suits me to do so.

BR, Lars.