Package Details: noisetorch 0.11.5-1

Git Clone URL: (read-only, click to copy)
Package Base: noisetorch
Description: Real-time microphone noise suppression on Linux.
Upstream URL:
Licenses: GPL3
Provides: noisetorch
Submitter: erbrecht
Maintainer: miss_barfin (hashworks, Scrumplex)
Last Packager: Scrumplex
Votes: 41
Popularity: 3.49
First Submitted: 2020-12-11 15:09 (UTC)
Last Updated: 2022-04-08 19:06 (UTC)

Latest Comments

Scrumplex commented on 2021-05-18 11:37 (UTC)

To solve these issues once and for all I created this PR here:

With it we can now define version and distribution build-time, as well as disable the updater similarly.

hashworks commented on 2021-05-18 07:46 (UTC) (edited on 2021-05-18 07:47 (UTC) by hashworks)

Fine with me. Version seems to be set just fine if referenced by commit. But I don't think we need pkgver(), I expect this to be bumped manually.

fabiscafe commented on 2021-05-18 07:35 (UTC)

Not to piss on anyones work here. I don't think that you should use git tags as build source, since they can be manipulated by enforcing a new commit to be this and that tag. (correct me if I'm wrong here)

I'd suggest using the commit hash directly. In case of 0.10.1 it's this one: so -> ee91fea993138624dce47b4c0b626a99db25f656

Here the example pkgbuild

# Maintainer:  Travis Collins <erbrecht at pobox dot com>
# Contributor: Justin Kromlinger <>

# Note: The upstream maintainer does not allow ANY modifications
# to the source code. Please refrain from doing so.

pkgdesc='Real-time microphone noise suppression on Linux.'
depends=('pulseaudio' 'polkit')
makedepends=('go' 'cmake' 'git')

pkgver() {
  cd NoiseTorch
  git describe --tags | sed 's/-/+/g'

build() {
    export GOPATH="$srcdir/go"
    cd NoiseTorch/c/ladspa
    cd ${srcdir}/NoiseTorch
    export CGO_CFLAGS="${CFLAGS}"
    export CGO_LDFLAGS="${LDFLAGS}"
    export GOFLAGS="-buildmode=pie -trimpath -ldflags=-linkmode=external -mod=readonly -modcacherw"
    go generate
    go build -o bin/noisetorch
    go clean -modcache

package() {
    cd NoiseTorch
    install -D -m755 bin/noisetorch "${pkgdir}/usr/bin/noisetorch"
    install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    install -D -m644 assets/noisetorch.desktop "${pkgdir}/usr/share/applications/noisetorch.desktop"
    install -D -m644 assets/icon/LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/icon-LICENSE"
    install -D -m644 assets/icon/noisetorch.png "${pkgdir}/usr/share/icons/hicolor/256x256/apps/noisetorch.png"

The changes are


To get the source by commit as well as

pkgver() {
  cd NoiseTorch
  git describe --tags | sed 's/-/+/g'

To generate the pkgver by the git tag of that commit.

miss_barfin commented on 2021-05-16 22:04 (UTC)

@Fumon thanks, i updated the package this this updated patch, now noisetorch can be installed normaly

Fumon commented on 2021-05-16 20:50 (UTC)

If you're running into the same error as @foxite @karthikjayd and @mnqn on version 0.10.1-3, the patch file needs an update.

If you're doing a manual build, change main.patch to,

--- main.go     2021-05-16 15:53:15.287331017 -0400
+++ src/NoiseTorch-0.10.1/main.go       2021-05-16 15:53:21.954164782 -0400
@@ -25,7 +25,6 @@

-//go:generate go run scripts/embedversion.go
 //go:generate go run scripts/embedlicenses.go

 //go:embed c/ladspa/

Then run updpkgsums and the package should build properly.

mnqn commented on 2021-05-14 22:12 (UTC)

I'm facing the same Issue as @karthikjayd and @foxite. Package broken.

==> Starting prepare()...
patching file main.go
Hunk #1 FAILED at 25.
1 out of 1 hunk FAILED -- saving rejects to file main.go.rej
==> ERROR: A failure occurred in prepare().
error making: noisetorch

karthikjayd commented on 2021-05-13 10:19 (UTC)

I am facing the same issue that @foxite has pointed out.

==> Starting prepare()...
patching file main.go
Hunk #1 FAILED at 25.
1 out of 1 hunk FAILED -- saving rejects to file main.go.rej
==> ERROR: A failure occurred in prepare().
:: Packages failed to build: noisetorch-0.10.1-3

foxite commented on 2021-05-12 15:21 (UTC)

Hi, thanks for adopting this package. Unfortunately with the latest release I can no longer build this package -- I'm using yay, and this is the output:

==> Starting prepare()...
patching file main.go
Hunk #1 FAILED at 25.
1 out of 1 hunk FAILED -- saving rejects to file main.go.rej
==> ERROR: A failure occurred in prepare().
error making: noisetorch

This is the contents of main.go.rej:

--- main.go 2021-01-31 01:57:33.000000000 -0500
+++ main.go.1   2021-02-01 09:09:20.817150966 -0500
@@ -25,7 +25,6 @@

 //go:generate go run scripts/embedbinary.go c/ladspa/ librnnoise.go libRNNoise
 //go:generate go run scripts/embedbinary.go assets/patreon.png patreon.go patreonPNG
-//go:generate go run scripts/embedversion.go
 //go:generate go run scripts/embedlicenses.go

 type device struct {

I checked main.go and line 23 to 26 look like this:

//go:generate go run scripts/embedversion.go
//go:generate go run scripts/embedlicenses.go

//go:embed c/ladspa/

I'm not an expert on any of this but is that trying to remove a line which has already been made blank?

It seems likely that I'm the only person experiencing this, because the update was 5 days ago and nobody else has mentioned it. But it seems weird that I am getting an error which seems to be unrelated to anything on my machine.

erbrecht commented on 2021-04-05 12:38 (UTC)

We've actually been making an effort to move this into the official repos. I think I 100% agree with you though.

ainola commented on 2021-03-25 04:25 (UTC) (edited on 2021-03-25 04:30 (UTC) by ainola)

What I'm arguing is that it doesn't matter what the license says. The license could explicitly say "arch linux users can never use this package" but that doesn't mean anything because this is a build script, not the program itself. We're doing nothing but providing the recipe for users to build/install locally on their machines. The author is mistakenly thinking that they have control over what users do with source that is made available to the public. It doesn't matter if it's GPL, proprietary, or ultra-illegal-you-cannot-change-anything-because-i-said-so license.

Again, if this were in the official repos with pre-built packages then it'd be a different story.

erbrecht commented on 2021-03-24 12:51 (UTC)

You may be right, but it's a little unclear. Section 7c states that a GPLv3 licensor can apply additional terms:

Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version.

It doesn't really say this is a requirement only for redistribution or packaged versions, so I'm not really sure if it's enforceable.

Either way, I think I'm pretty much done maintaining this. I thought it would be an interesting foray into building packages, but it has been a bad experience. Normally this kind of thing is right up my alley, and I love that I've been able to contribute a bit to Arch.

If someone wants to take over I'd be glad to help transition. I actually started a bit of work to create a new make target for distros that use go build tags to selectively include go source instead of patching things ( If upstream accepts this method, which they stated they would, they wouldn't be asking us to rename the package. I just don't want to maintain this package since it's basically been an uphill battle from the start.

ainola commented on 2021-03-22 15:47 (UTC) (edited on 2021-03-22 21:20 (UTC) by ainola)

I do not believe that we are under any obligation to change the name so long as this is in the AUR. This is not distribution of pre-built software, this is a build script for users to create binaries for themselves. It's why the AUR is able to have myriad proprietary softwares in the repository. If Arch were to include noisetorch in the official repositories then I imagine Arch would then need to solicit a fork.

Unless there's going to be serious potential ramifications (legal threats, pushing the dev into going open-code in some misguided attempt to "fix" the situation, etc.) it seems like the package can just continue to live, patched, in the AUR alongside countless other softwares that upstream authors do not bless.

The author has demonstrated a lack of tact that ensures a barrier to mutuality; I propose we just continue doing our thing in the AUR and make software that's proper in accordance to sane packaging.

znoble360 commented on 2021-02-28 17:53 (UTC)

Or noiseflashlight

Widowan commented on 2021-02-28 15:23 (UTC)

Can't it be like "noisetorch-patched" or something?

Svenstaro commented on 2021-02-25 17:37 (UTC)

I'm not really sure where this hostility from upstream is coming from. I suppose you can just rename it to not-noisetorch and move on with this. :p what a silly upstream move.

erbrecht commented on 2021-02-25 15:54 (UTC)

I was notified by the owner of the repo that starting with the next release, they will be adding a restriction to modified versions of the application:

Addition to the license is here:

We'll need to either change the name of this package, or stop distributing it this way. I'm open to naming suggestions, but with this latest change we can't push this into [community] as-is.

erbrecht commented on 2021-02-19 14:11 (UTC)

It looks like their own implementation. They mentioned in the release notes that it's their own, and the repo doesn't seem to contain any submodules or links to other repos.

I created a PKGBUILD for their ladspa implementation:

I also updated my experimental PKGBUILD to properly link the library:

Everything seems to work fine.

Svenstaro commented on 2021-02-09 19:27 (UTC)

Are you sure it's their own implementation or that it's just copied into there from somewhere? I'd ideally like to devendor it entirely (and build the C stuff in (a) separate package(s)) and then just link to it. Think that's doable?

erbrecht commented on 2021-02-09 15:18 (UTC)

Ok, after looking at this for just a bit, here is what I see. Initially, noisetorch was using the ladspa plugin provided by (which in turn uses xiph's rnnoise library. It was embedding the binary, and I modified it to make use of the actual shared library.

Now, noisetorch has its own implementation of the ladspa plugin, again based on xiph's rnnoise library (provides I think what we need is the that is built here I have a PKGBUILD available here It tries to rely on the shared library, but it doesn't work since it's not the ladspa plugin (I think).

erbrecht commented on 2021-02-09 14:30 (UTC)

Sorry it took a while. I'm now setting the capability directly on the binary in the install file. Thanks for that suggestion.

I took a look at your changes and I implemented most of them except the dependency 2. I'm also working on linking rnnoise. It should be pretty straight forward. I'll try to get to that as soon as I can.

I originally had hicolor-icon-theme as a dependency but removed it after this feedback ( It seems to make sense.

Also, export GOPATH="$srcdir/go" is there so that the go build dependencies don't end up in the user's system. go clean -modcache cleans the source directory after the build so all those dependencies don't take up space. I'd be inclined to leave those unless there is a pressing reason to remove them. I did remove the go clean command from the prepare function since it's not really necessary before the build.

Svenstaro commented on 2021-02-05 15:29 (UTC)

Yeah, that sounds like a sound idea. Also, take a look at my changes and perhaps adopt most of them.

malteger commented on 2021-02-04 09:42 (UTC)

Is it the desired behaviour that the noisetorch binary sets the capabilities for itself? As noisetorch is no longer usable without the capability cap_sys_resource I would assume that the best place to set it is the install file (like it is done for e.g. ping).

Svenstaro commented on 2021-02-03 15:48 (UTC)

Ideally I'd want to separately package the C dependencies and dynamically link them in. As a start, I packaged rnnoise. Can you try linking that dynamically instead of the weird soname embedding that's going on?

Apart from that, this would be my current PKGBUILD:

erbrecht commented on 2021-02-03 14:14 (UTC)

I did some minor cleanup on the PKGBUILD. It follows the go packaging guidelines as far as I can tell, and I believe it is reproducible. Updating the pkgver in the PKGBUILD is all I have been doing for the past couple releases, otherwise the current version builds no problem without intervention.

Svenstaro commented on 2021-02-03 13:41 (UTC)

Make sure to clean up the package and make it reproducible/make it comply with go package guidelines.

erbrecht commented on 2021-02-03 13:39 (UTC)

@Svenstaro Absolutely not, go right ahead! Is there anything you need me to do?

@znoble360 The readme is indeed incorrect, but if the application prompts for creds to set the capability, it appears to operates on itself instead of a fixed path 1 and 2.

That executable function might have problems dealing with symlinks, but if the package is installed as-is, it should work. I haven't touched the setcap command on my system and I see:

$ getcap /usr/bin/noisetorch
/usr/bin/noisetorch cap_sys_resource=eip

Svenstaro commented on 2021-02-03 06:56 (UTC)

You mind me pulling this into [community]?

znoble360 commented on 2021-02-01 23:50 (UTC)

After a bit of futzing around, I figured out why the CAP_SYS_RESOURCE authorization was failing for me. It looks like since you install noisetorch in /bin instead of home and the original attempts to authorize noisetorch in the user home, the user can't use the autofix for CAP_SYS_RESOURCE. The official command in the git sudo setcap 'CAP_SYS_RESOURCE=+ep' ~/.local/bin/noisetorch also doesnt work for the same reason, so one must instead replace ~/.local/bin/noisetorch with the new location of the binary.

erbrecht commented on 2020-12-16 14:54 (UTC)

for the package conflicts, should the -bin -git variants still conflict with this one? so basically this package conflicts with nothing, while the other -git -bin variants contain all the conflicts?

aviallon commented on 2020-12-15 21:21 (UTC)

Hello, thanks for this package! Version 0.9.0 is went out three days ago :)

Svenstaro commented on 2020-12-13 03:54 (UTC) (edited on 2020-12-13 03:54 (UTC) by Svenstaro)

Hey, thanks for the package. A note: Regular packages should not conflict with their non-regular (-git, -bin) variants. However, conversely, those odd packages should conflict with the regular one. The idea is that the regular packages should be ignorant of the irregular ones.