| View previous topic :: View next topic |
| Author |
Message |
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
 Posted: Mon Jun 24, 2024 12:11 pm Post subject: [Solved] Firefox support for ALSA audio _input_ |
 |
|
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.
Last edited by lars_the_bear on Wed Jun 26, 2024 8:36 am; edited 1 time in total |
|
| Back to top |
|
 |
RumpletonBongworth
n00b
Joined: 17 Jun 2024
Posts: 74
|
| Posted: Mon Jun 24, 2024 1:33 pm Post subject: Re: Firefox support for ALSA audio _input_ |
|
|
| lars_the_bear wrote: | | 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. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Mon Jun 24, 2024 6:03 pm Post subject: Re: Firefox support for ALSA audio _input_ |
|
|
| RumpletonBongworth wrote: | | 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. |
|
| Back to top |
|
|
RumpletonBongworth
n00b
Joined: 17 Jun 2024
Posts: 74
|
| Posted: Mon Jun 24, 2024 6:05 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Mon Jun 24, 2024 6:16 pm Post subject: |
|
|
| RumpletonBongworth wrote: | | 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. |
|
| Back to top |
|
|
RumpletonBongworth
n00b
Joined: 17 Jun 2024
Posts: 74
|
| Posted: Mon Jun 24, 2024 6:50 pm Post subject: |
|
|
| Using the apulse wrapper is as close to clicking a button as it gets, I think. Certainly not as convenient. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20484
|
| Posted: Mon Jun 24, 2024 9:22 pm Post subject: Re: Firefox support for ALSA audio _input_ |
|
|
| lars_the_bear wrote: | | 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: | Quote: | 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 ;)
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Ralphred
l33t
Joined: 31 Dec 2013
Posts: 652
|
| Posted: Mon Jun 24, 2024 11:00 pm Post subject: |
|
|
| RumpletonBongworth wrote: | | 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. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Tue Jun 25, 2024 7:20 am Post subject: Re: Firefox support for ALSA audio _input_ |
|
|
[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. |
|
| Back to top |
|
|
Ralphred
l33t
Joined: 31 Dec 2013
Posts: 652
|
| Posted: Tue Jun 25, 2024 12:38 pm Post subject: Re: Firefox support for ALSA audio _input_ |
|
|
| lars_the_bear wrote: | | 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. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20484
|
| Posted: Tue Jun 25, 2024 12:54 pm Post subject: |
|
|
| lars_the_bear wrote: | | 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: | garrison wrote: | 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. |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
AJM
Apprentice
Joined: 25 Sep 2002
Posts: 195
Location: Aberdeen, Scotland
|
| Posted: Tue Jun 25, 2024 1:05 pm Post subject: |
|
|
| Ralphred wrote: | | *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! |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Tue Jun 25, 2024 1:32 pm Post subject: |
|
|
| AJM wrote: |
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. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Tue Jun 25, 2024 1:38 pm Post subject: |
|
|
| pjp wrote: | | 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. |
|
| Back to top |
|
|
Ralphred
l33t
Joined: 31 Dec 2013
Posts: 652
|
| Posted: Tue Jun 25, 2024 2:18 pm Post subject: |
|
|
| AJM wrote: | | 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.
| lars_the_bear wrote: | | 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. |
|
| Back to top |
|
|
AJM
Apprentice
Joined: 25 Sep 2002
Posts: 195
Location: Aberdeen, Scotland
|
| Posted: Tue Jun 25, 2024 3:49 pm Post subject: |
|
|
The only config file I can find for anything ALSA related is /etc/asound.conf which simply contains the lines:
| Code: | defaults.pcm.!card Generic_1
defaults.pcm.!device 0
defaults.ctl.!card Generic_1
|
|
|
| Back to top |
|
|
saturnalia0
Apprentice
Joined: 13 Oct 2016
Posts: 158
|
| Posted: Tue Jun 25, 2024 10:18 pm Post subject: |
|
|
firefox-bin works for me. I start it like so:
| Code: |
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: |
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.... |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2727
Location: Here and Away Again
|
| Posted: Wed Jun 26, 2024 4:50 am Post subject: |
|
|
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.
_________________
Kindest of regardses. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Wed Jun 26, 2024 8:32 am Post subject: |
|
|
| Chiitoo wrote: | 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. |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2727
Location: Here and Away Again
|
| Posted: Wed Jun 26, 2024 9:02 am Post subject: |
|
|
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...
_________________
Kindest of regardses. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Wed Jun 26, 2024 11:06 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2727
Location: Here and Away Again
|
| Posted: Wed Jun 26, 2024 1:14 pm Post subject: |
|
|
| lars_the_bear wrote: | | 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. ^^;
| lars_the_bear wrote: | | 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.
| lars_the_bear wrote: | | 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?
| lars_the_bear wrote: | | 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.
| lars_the_bear wrote: | | 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...
_________________
Kindest of regardses. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20484
|
| Posted: Thu Jun 27, 2024 11:22 pm Post subject: |
|
|
| lars_the_bear wrote: | 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.
| lars_the_bear wrote: | | 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.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3420
|
| Posted: Fri Jun 28, 2024 1:08 am Post subject: |
|
|
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).
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 517
|
| Posted: Fri Jun 28, 2024 7:36 am Post subject: |
|
|
| pjp wrote: | 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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
