Date: Thu, 15 Jul 2021 10:52:29 +0200 From: Ralf Mardorf <ralf-mardorf@riseup.net> To: freebsd-questions@freebsd.org Subject: Re: What the hell starts pulseaudio?! Message-ID: <20210715105229.50fee7b3@archlinux> In-Reply-To: <20210715063116.85e42de5c276f40c8920ee2c@sohara.org> References: <5b18f5de-7aae-a226-88cd-a210507d5c5@gmail.com> <CAM8r67CB5wye72e_FCVx8QaxyW1U=9eFSP4tJopSVYnaEwW2LQ@mail.gmail.com> <72194e9f-261c-c3da-996-f8e1bcad2164@gmail.com> <CAM8r67BZPJiWtxY75DRw9R1pZgOgE1PvYQ_g6_BgEtHmWCandg@mail.gmail.com> <acc7c26d-2186-4725-be62-7b1d5a9e25f@gmail.com> <CAM8r67CL_Q2se9Df_63N9x6X=YEkJzzqpMQyVObpQXPCzTt4Kg@mail.gmail.com> <f41a463d-46d9-903d-2a19-ef64a9636d7b@googlemail.com> <20210715063116.85e42de5c276f40c8920ee2c@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Jul 2021 06:31:16 +0100, Steve O'Hara-Smith wrote:
>you'll almost certainly have to build it from source
This could take hours, at least on Linux with an Intel Celeron dual-core
CPU G1840 @ 2.80GHz, with 8 GiB RAM, so a regular tmpfs is too small to
build Firefox and it needed to get build on a SATA3 SSD. Let alone
building the Electron framework, based on Chromium, IIRC it took 1/4
day. There's no reason that it can be expected to compiled faster on
FreeBSD, just a computer with more horsepower can workaround this issue.
Building those bloated browsers takes way longer then building kernels
and due to security related updates you have to build browsers very
often.
On Linux pulseaudio became a default annoyance earlier than on FreeBSD
and in the beginning there where absolutely no working ways just to
disable an installed pulseaudio.
If you just delete the pulseaudio related files, nothing that was
compiled against it breaks, resp. audio might break, if no alternative
sound architecture or a workaround is provided, but even then Firefox
works without audio.
On Linux an alternative apulse worked and it might still work, I don't
know, since the packages of the Linux distro I'm using provide Firefox
build against jack and ALSA, too.
I still prefer to build empty dummy packages on Linux to fulfil
dependencies of packages that were build against pulseaudio, instead of
installing and disabling pulseaudio.
Assuming "autospawn = no" is a solution that works without issues
nowadays, the problem would be solved without a dirty hack. However,
I'm in favour of the dirty hack, since it works without fail, even if a
drop-in file or something else that gets introduced the other day, will
break a solution that works today.
If you rely on using Linux software on your FreeBSD install, than I've
got bad news for you. If you prefer to stay with a reliable old-school
environment, you are forced to get used to dirty hacks or to fork
software, since it's even not granted that annoying things can be
disabled or replaced by something else via config flags at build time.
My all-day workstation is a _rolling release_ Linux distro, that
follows upstream as close and fast as possible.
Installed
local/apulse 0.1.13-1
PulseAudio emulation for ALSA
multilib/lib32-libpulse 14.2-2
A featureful, general-purpose sound server (32-bit client libraries)
extra/pulseaudio 2013.08.18-1
Dummy package
extra/pulseaudio-alsa 1:1.2.5-2
ALSA Configuration for PulseAudio
extra/pulseaudio-bluetooth 2017.12.19-1
Dummy package
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210715105229.50fee7b3>