Created attachment 241649 [details] Patch for opus - Switch to Meson, builds much faster than Autotools and integrates with ports framework better - Add option for NEON instructions on ARM 32-bit - Enable LTO by default, improves encoding performance with more than 10% on my amd64 and aarch64 boxes Compile and runtime tested on FreeBSD 13.2-RELEASE (aarch64) (make, make check-plist, make test) Compile and runtime tested on FreeBSD 13.2-RELEASE (amd64) (make, make check-plist, make test) Poudriere testport OK 12.4-RELEASE (amd64) Poudriere testport OK 13.1-RELEASE (i386) Poudriere testport OK 13.2-RELEASE (amd64) Tested with following users in Poudriere (13.2-RELEASE, amd64): games/DDNet net/asterisk16 net/asterisk18 audio/audacity multimedia/butt www/chromium games/easyrpg-player audio/easytag devel/electron18 devel/electron19 multimedia/ffmpeg multimedia/ffmpeg4 net/freeswitch audio/gogglesmm audio/gstreamer1-plugins-opus multimedia/handbrake games/iortcw audio/jack-example-tools audio/jack www/janus audio/kwave audio/libopusenc audio/libsndfile devel/libspice-server net/mediastreamer games/moonlight-embedded audio/mumble audio/musicpd audio/opus-tools audio/opusfile audio/py-fmoo-audiotools net-im/py-toxcore-c multimedia/qmmp-qt5 multimedia/qmmp-qt6 www/qt5-webengine www/qt6-webengine net/sems multimedia/snapcast deskutils/spice-gtk comms/svxlink net-im/telegram-desktop net-im/tox_extension_messages net-im/tox net-im/toxext net-im/uTox www/ungoogled-chromium multimedia/vlc editors/vscode games/warzone2100 net/wireshark net/xrdp net/xrdp-devel emulators/yuzu
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ffa50ba20a61a2daa3bd44dceaf76061683acebd commit ffa50ba20a61a2daa3bd44dceaf76061683acebd Author: Christian Weisgerber <naddy@FreeBSD.org> AuthorDate: 2023-04-25 14:54:13 +0000 Commit: Christian Weisgerber <naddy@FreeBSD.org> CommitDate: 2023-04-25 15:17:15 +0000 audio/opus: update to 1.4 This new release brings the following improvements: - Improved tuning of the Opus in-band FEC (LBRR) - Added an OPUS_SET_INBAND_FEC(2) option that turns on FEC, but does not force SILK mode (FEC will be disabled in CELT mode) - Improved tuning and various fixes to DTX PR: 270996 audio/opus/Makefile | 6 ++++-- audio/opus/distinfo | 6 +++--- audio/opus/pkg-plist | 2 +- 3 files changed, 8 insertions(+), 6 deletions(-)
I have updated the port to 1.4. I don't want to switch to meson. As far as I understand, WITH_LTO is to be set in /etc/make.conf. It is not an option for an individual port. The default run-time CPU detection will pick up NEON support, a separate OPTION is useless.
Is there a technical reason for not switching? I can't see any disadvantages and we already spend a lot of time not compiling code during builds instead processing slow shell scripts. Distros such as Alpine, Arch, Gentoo uses it and projects overall are also moving to Meson additionally it's a lot easier to debug. Given the increased usage we're also likely to benefit from this if we need support upstream. Regarding lto, you can either use CONFIGURE_ARGS (if supported) or *FLAGS manually however we encourge usage of framework features. I'd like to think that we strive to make overall user experience as good as possible and not make things unnecessary slow. We already have a bunch of ports the benefits from LTO and enables it to improve overall experience. That includes a bunch of multimedia related ones. We also makes use of it for Rust ports (not all) https://cgit.freebsd.org/ports/tree/Mk/Uses/cargo.mk#n142 for example. Unless I'm mistaken the port forces fixed-point code path on ARM 32-bit which is dated practice since we only support ARMv6 and ARMv7 with FPU (upstream defaults to float) which is why I added an option and run-time detection doesn't work on ARM 32-bit, at least when building using Poudriere). Best regards, Daniel
Is there a technical reason to switch? Meson support was merely added by upstream. It doesn't replace autotools and in fact meson pulls the library version from the configure script. Personally, I have longtime experience with dealing with autotools. Note that ARCH=="arm" only applies to ARMv5, which I think is still supported for 12.x. By contrastm, "armv6" and "armv7" will not be configured with fixed-point code. If run-time CPU detection (rtcd) is broken on armv[67], that's a bug.
It's much faster, easier to debug, integrates better withour framework (and produces much faster binaries with LTO). There's usually a transition time when projects switches build frameworks but in this case I don't really see why not.