Crackling audio (update: if no PTY allocated)

I noticed that when i use jamesdsp, i've crackling sound from time to time with pipewire.
I tried to force the quantum even to 512 to no avail and without jamesdsp I can safely go down to 32.

[plasmauser@Gozer ~]$ uname -a
Linux Gozer 5.17.1-arch1-1 #1 SMP PREEMPT Mon, 28 Mar 2022 20:55:33 +0000 x86_64 GNU/Linux
[plasmauser@Gozer ~]$ pacman -Q jamesdsp
jamesdsp-git 2.3.r29.ga11f428-1
[plasmauser@Gozer ~]$ pacman -Q pipewire
pipewire 1:0.3.49-1

I'm not doing anything special, just playing an mp3 and use an equalizer from jamesdsp.
The crackling appears when firefox is loading a page or maybe when i maximize a window.
I even tried to set jamesdsp to realtime priority.

I have an update.
If i start jamesdsp from the terminal, I've NO xruns
If i start the application by clicking on the .desktop file -> i've xruns
If i start it with the kde session -> i've xruns (probably because of .desktop file)
If i start it by the .desktop file, but set the .desktop file to open a terminal for the app, i've NO xruns.

Just ignorant guessing follows:
Could it be something realted to stdin/stdout streams not connected?

if i start jamesdsp from terminal: (NO XRUNS)

koko@Gozer# ps -ef|grep jamesdsp
koko     3059075 3049167 39 10:09 pts/5    00:00:01 jamesdsp
koko     3059147 3049167  0 10:09 pts/5    00:00:00 grep --colour=auto jamesdsp

If i start it from the .desktop file: (XRUNS)

koko@Gozer# ps -ef|grep jamesdsp
koko     3059424 3035661 40 10:10 ?        00:00:01 /bin/jamesdsp
koko     3059476 3049167  0 10:10 pts/5    00:00:00 grep --colour=auto jamesdsp

Note, no pts is allocated for it.
So my workaround, stolen from: https://stackoverflow.com/questions/7114990/pseudo-terminal-will-not-be-allocated-because-stdin-is-not-a-terminal

Is to modify the .desktop file by executing:

unbuffer -p /usr/bin/jamesdsp

That way, even if i start jamesdsp from the newly created .desktop file, PTS is allocated:

koko@Gozer# ps -ef|grep jamesdsp
koko     3060927 3035661  0 10:12 ?        00:00:00 tclsh /bin/unbuffer -p /usr/bin/jamesdsp
koko     3060928 3060927 29 10:12 pts/4    00:00:01 /usr/bin/jamesdsp
koko     3061004 3049167  0 10:12 pts/5    00:00:00 grep --colour=auto jamesdsp

...and i've no more XRUNS.

I don't know if other desktop environments do allocate PTY to apps started from .desktop files and by the fact that nobody filed bugs for this issue makes me think that the problem could be related to my system.
Still, the workaround suggest it is a bug in jamesdsp.

What do you think?

Thanks for your detailed report!
I've done some testing, and I couldn't reproduce the issue. I tested it with Pipewire version 0.3.48 and the latest version (0.3.50); however, not with the same version you used (0.3.49). There's a chance this particular version introduced a regression that got fixed with the latest version. Perhaps updating Pipewire could help.

Other than that, I'm not sure where the root of this issue could be; I'm running KDE too, and I haven't yet noticed any issues related to their .desktop-implementation. I'm only using stdout to print logs, and there shouldn't be any side effects if it isn't attached to a PTY. For now, I'll add some troubleshooting instructions about this to the readme in case other people run into the same problem.

@kokoko3k

@kokoko3k
Where do you take the unbuffer script/binary from? It's mentioned nowhere in the linked so post

@kokoko3k

@kokoko3k Where do you take the unbuffer script/binary from? It's mentioned nowhere in the linked so post

Hi sorry, it is from the "expect" package.
This is in Archlinux.
Do you have the same issue?
Does unbuffer fix it for you?

I'm still trying, but it looks like it's solved.
I still get crackling if I overload it (enable as many effects as possible, but then I get crackling even when run from terminal).
The tty is allocated at least.
However, the -p option does not work for me, I had to remove it (instantly crashes/gets killed if not run from terminal).

I don't believe it yet, but it seems that the update that was released in the AUR some minutes ago did fix it.

Nothing spectacular changed, but as of now (10 minutes after the update) the crackling is gone.
So either it's because compilation screwed up first time or this line did a difference: qmake-qt5 ../JDSP4Linux.pro

This is the whole diff between the new and the old version of the AUR git:

git diff bd261f23ed2a3874d7a9e683fa1dbd2702f5ed60 master
diff --git a/.SRCINFO b/.SRCINFO
index e678e95..98d7565 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,9 +1,10 @@
 pkgbase = jamesdsp
    pkgdesc = An audio effect processor for PipeWire clients
    pkgver = 2.3
-   pkgrel = 3
+   pkgrel = 4
    url = https://github.com/Audio4Linux/JDSP4Linux
    arch = x86_64
+   arch = aarch64
    license = GPL3
    makedepends = git
    depends = glibmm
diff --git a/PKGBUILD b/PKGBUILD
index f1ccc33..8eebae5 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,9 +1,9 @@
 # Maintainer: Mark Wagie <mark dot wagie at tutanota dot com>
 pkgname=jamesdsp
 pkgver=2.3
-pkgrel=3
+pkgrel=4
 pkgdesc="An audio effect processor for PipeWire clients"
-arch=('x86_64')
+arch=('x86_64' 'aarch64')
 url="https://github.com/Audio4Linux/JDSP4Linux"
 license=('GPL3')
 depends=('glibmm' 'pipewire' 'qt5-svg')
@@ -45,7 +45,12 @@ build() {
   cd "$srcdir/JDSP4Linux"
 
   pushd build
-  qmake-qt5 ..
+
+  if [ $CARCH == "x86_64" ]; then
+    qmake-qt5 ../JDSP4Linux.pro
+  elif [ $CARCH == "aarch64" ]; then
+    qmake-qt5 ../JDSP4Linux.pro CONFIG+=NO_CRASH_HANDLER
+  fi
   make
   popd
 }

I'm also having this issue of crackling audio, I use a PulseAudio distro namely Mint, it happens randomly, is a little bit annoying but can't live without this DSP

I have tried running this DSP without the autostart option from the app itself, but from the Linux Startup apps, and it seems the audio crackling is a lot less prone to happen, or even doesn't happen at all, weird

I have tried running this DSP without the autostart option from the app itself, but from the Linux Startup apps, and it seems the audio crackling is a lot less prone to happen, or even doesn't happen at all, weird

This would be coherent with my findings about PTY allocation.

I have tried running this DSP without the autostart option from the app itself, but from the Linux Startup apps, and it seems the audio crackling is a lot less prone to happen, or even doesn't happen at all, weird

This would be coherent with my findings about PTY allocation.

So probably this bug can be easily fixed by the author, yes is true it rarely happens,or probably it doesn't happen at all, now the sound is great.

Hi, I had this problem too.
I also use Arch and I have installed EasyEffects and JameDSP.
Using a discrete headphone AMP with a planar headphone those cracking/popping was VERY annoying.
At first I though was a DSP issue but it was persistent also with EasyEffects so investigating a little deeper I found could be a Pipewire issue.
https://bbs.archlinux.org/viewtopic.php?id=262981
Changing those lines eradicate all the cracking/popping everywhere (removing the comments and substituting the numbers):
/usr/share/pipewire/pipewire.conf
default.clock.quantum = 2048 #1024
default.clock.min-quantum = 1024 #32
default.clock.max-quantum = 4096 #2048

I don't know if my issue is related to this one or not, but I also have audio crackling, but in my case it always happens when KDE notification popup shows up (with the notification bell)

Changing those lines eradicate all the cracking/popping everywhere (removing the comments and substituting the numbers): /usr/share/pipewire/pipewire.conf default.clock.quantum = 2048 #1024 default.clock.min-quantum = 1024 #32 default.clock.max-quantum = 4096 #2048

that did it for me too, so happy I got it fixed

Be warned, that those lines prevent underruns by highering the output latency alot.

Navigation Menu

Repository navigation

Crackling audio (update: if no PTY allocated) #47

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Crackling audio (update: if no PTY allocated) #47

Description

Activity

kokoko3k commented on Apr 15, 2022

kokoko3k commented on Apr 15, 2022

timschneeb commented on Apr 18, 2022

binarynoise commented on Aug 12, 2022

kokoko3k commented on Aug 12, 2022

binarynoise commented on Aug 12, 2022

binarynoise commented on Aug 12, 2022

viggen66 commented on Oct 19, 2022

viggen66 commented on Nov 9, 2022

kokoko3k commented on Nov 9, 2022

viggen66 commented on Nov 9, 2022

giostark commented on Apr 9, 2023

dev-rfc commented on Feb 26, 2024

itsmeteddyhere commented on Dec 30, 2024

kokoko3k commented on Dec 30, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions