EasyEffects priority?

[gorman42]

Hi! First of all thanks for an amazing piece of software, that allowed to transport my REW created parametric EQ for my monitor loudspeakers to Linux Mint. :-)

I'm currently copying lots of files from one external USB3 hard drive to another external USV3 hard drive, while browing on Firefox. Sometimes I hear small glitches, as if the processing is getting interrupted for a millisecond (or something)...

So I opened system monitor to check priorities. I see pipewire, pipewire-pulse and wireplumber with Very High priority but easyeffects has Normal priority. Could this be the reason of glitching? How should I raise it, in case it can help? Sorry but I'm a real newbie when it comes to Linux.

I installed pipewire using this guide, if it matters: https://lowtechlinux.com/2022/04/26/go-full-pipewire-on-ubuntu-22-04-and-all-family-derivatives/

And EasyEffects as a flatpak from Software Manager in Mint. Version is 7.0.3.

Edit: forgot to provide info on my system (CPU utilization stays around 20-25% for all four threads). Here goes:

System:
Kernel: 5.15.0-69-generic x86_64 bits: 64 compiler: gcc v: 11.3.0
Desktop: Cinnamon 5.6.8 Distro: Linux Mint 21.1 Vera
base: Ubuntu 22.04 jammy
Machine:
Type: Mini-pc System: Intel Client Systems product: NUC11TNKi3
v: M11929-405 serial:
Mobo: Intel model: NUC11TNBi3 v: M11908-404 serial:
UEFI: Intel v: TNTGL357.0064.2022.0217.1550 date: 02/17/2022
CPU:
Info: dual core model: 11th Gen Intel Core i3-1115G4 bits: 64 type: MT MCP
arch: Tiger Lake rev: 1 cache: L1: 160 KiB L2: 2.5 MiB L3: 6 MiB
Speed (MHz): avg: 1828 high: 2489 min/max: 400/4100 cores: 1: 1301
2: 2489 3: 2177 4: 1345 bogomips: 23961
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: Intel driver: i915 v: kernel bus-ID: 00:02.0
Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
unloaded: fbdev,vesa gpu: i915 resolution: 2560x1440~60Hz
OpenGL: renderer: Mesa Intel UHD Graphics (TGL GT2) v: 4.6 Mesa 22.2.5
direct render: Yes
Audio:
Device-1: Intel Tiger Lake-LP Smart Sound Audio driver: snd_hda_intel
v: kernel bus-ID: 00:1f.3
Device-2: Thesycon System & Consulting GmbH DX3 Pro type: USB
driver: snd-usb-audio bus-ID: 3-7.1:5
Sound Server-1: ALSA v: k5.15.0-69-generic running: yes
Sound Server-2: PulseAudio v: 15.99.1 running: no
Sound Server-3: PipeWire v: 0.3.48 running: yes
Network:
Device-1: Intel Wi-Fi 6 AX201 driver: iwlwifi v: kernel bus-ID: 00:14.3
IF: wlo1 state: down mac:
Device-2: Intel Ethernet I225-LM driver: igc v: kernel port: N/A
bus-ID: 58:00.0
IF: enp88s0 state: up speed: 1000 Mbps duplex: full mac:
IF-ID-1: eddie state: unknown speed: 10 Mbps duplex: full mac: N/A
Bluetooth:
Device-1: Intel AX201 Bluetooth type: USB driver: btusb v: 0.8
bus-ID: 3-10:4
Report: hciconfig ID: hci0 rfk-id: 0 state: down
bt-service: enabled,running rfk-block: hardware: no software: yes
address:
Drives:
Local Storage: total: 29.33 TiB used: 22 TiB (75.0%)
ID-1: /dev/nvme0n1 vendor: Crucial model: CT250P2SSD8 size: 232.89 GiB
temp: 40.9 C
ID-2: /dev/sda type: USB vendor: Western Digital model: WD Elements 25A3
size: 12.73 TiB
ID-3: /dev/sdb type: USB vendor: Western Digital model: WD Elements 25A3
size: 16.37 TiB
Message: No optical or floppy data found.
Partition:
ID-1: / size: 227.68 GiB used: 96.05 GiB (42.2%) fs: ext4
dev: /dev/nvme0n1p2
ID-2: /boot/efi size: 511 MiB used: 6.1 MiB (1.2%) fs: vfat
dev: /dev/nvme0n1p1
Swap:
ID-1: swap-1 type: file size: 2 GiB used: 1.05 GiB (52.3%) file: /swapfile
Sensors:
System Temperatures: cpu: 40.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 331 Uptime: 1d 15h 4m Memory: 15.29 GiB used: 7.1 GiB (46.4%)
Init: systemd runlevel: 5 Compilers: gcc: 11.3.0 Packages: 2481
Shell: system info.sh inxi: 3.3.13

[wwmm]

I see pipewire, pipewire-pulse and wireplumber with Very High priority but easyeffects has Normal priority. Could this be the reason of glitching? How should I raise it, in case it can help? Sorry but I'm a real newbie when it comes to Linux.

PipeWire's filters run in a realtime thread managed by PipeWire. So the audio processing is happening at high priority. I think there are ways to customize this through PipeWire's configuration files. But I have never done it myself.

Run pw-top while playing something. The columns QUANT and RATE will help to know what is the estimated latency used by PipeWire. My guess is that PipeWire is setting the latency "too low" on your system. And when the latency is too low no amount of "high priority" will avoid glitches.

[gorman42]

Run pw-top while playing something. The columns QUANT and RATE will help to know what is the estimated latency used by PipeWire. My guess is that PipeWire is setting the latency "too low" on your system. And when the latency is too low no amount of "high priority" will avoid glitches.

I see

I don't know how to interpret it, to be honest. :-)

[wwmm]

The estimated latency used by PipeWire in this case is 1024 / 176400 = 0.0058 seconds. It is very low and there are systems that are not able to properly handle it. It depends on the combination of soundcard hardware, driver, CPU, etc.

There are ways to change PipeWire's configuration files in a way that the minimum quantum size does not get "too low". But before taking this route I would take a look at this https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#quantum-ranges to set a temporary fixed quantum value that is higher than the one in the image. 1024 is fine with 48000 Hz and 44100 Hz but with 176400 Hz you may have to use higher quantum values like 4096. This would lead to a latency of about 20 milliseconds. IF your system struggles only when intense io is happening 20 ms should be enough.

[gorman42]

There are ways to change PipeWire's configuration files in a way that the minimum quantum size does not get "too low". But before taking this route I would take a look at this https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#quantum-ranges to set a temporary fixed quantum value that is higher than the one in the image. 1024 is fine with 48000 Hz and 44100 Hz but with 176400 Hz you may have to use higher quantum values like 4096. This would lead to a latency of about 20 milliseconds. IF your system struggles only when intense io is happening 20 ms should be enough.

Ok, I set it at 4096 as suggested. Glitches seem to be gone. How can I make it permanent? I did not want to ask and tried understanding from the page you linked. But using

pw-metadata -n settings 0 clock.quantum 4096

Actually leads to QUANT being 2048, while using

pw-metadata -n settings 0 clock.force-quantum 4096

sees QUANT at 4096

I tried clock.min-quantum 4096 with no luck too. Now I even fear to have messed up the configuration, as that page does not mention how to go back to default, initial values. Documentation should always include default values, when the user can change them, IMHO.

[gorman42]

Also, I already have client.conf, pipewire.conf and pipewire-pulse.con in ~/.config/pipewire, no need to explain about those (how to create them, where to put them, etc.). I mention this as I imagine that I need to act on those files.

[wwmm]

Now I even fear to have messed up the configuration, as that page does not mention how to go back to default, initial values.

Quantum settings done with pw-metadata are not persistent. A reboot or maybe even a logout is enough to revert them.

[gorman42]

Ok, I think I got it.

I set

default.clock.min-quantum   = 4096
default.clock.max-quantum   = 4096

in pipewire.conf under ~/.config/pipewire.

Then systemctl --user restart pipewire.service pipewire-pulse.socket, ended easyeffects process (is there another way to restart?)

Now QUANT is set at 4096 with pw-top.

I hope I did it correctly.

[wwmm]

Then systemctl --user restart pipewire.service pipewire-pulse.socket, ended easyeffects process (is there another way to restart?)

Unfortunately EasyEffects has to be killed and restarted manually after restarting PipeWire. Implementing automatic reinitialization is a little hard.

I hope I did it correctly.

It seems fine. The only drawback of this workaround is that if you use lower sampling rates in the future you will have higher latency. The estimated latency is the quantum value divided by the sampling rate. So if you reduce the sampling rate without changing the quantum the overall latency will be higher than the one you have now. If it will be noticeable by ear is hard to say.

[gorman42]

Unfortunately EasyEffects has to be killed and restarted manually after restarting PipeWire. Implementing automatic reinitialization is a little hard.
No problem. I just wanted to be sure I wasn't missing something. It's not as if, in normal use, I need to restart pipewire frequently. :-)

I hope I did it correctly.

It seems fine. The only drawback of this workaround is that if you use lower sampling rates in the future you will have higher latency. The estimated latency is the quantum value divided by the sampling rate. So if you reduce the sampling rate without changing the quantum the overall latency will be higher than the one you have now. If it will be noticeable by ear is hard to say.

I'm not in music production or anything. It's fine to upsample everything to 176.4.

Offtopic here but I banged my head for hours, trying to understand how the upsampling functions in DeadBeef interact with pipewire. Do you have any idea or know where I could look?

[wwmm]

Offtopic here but I banged my head for hours, trying to understand how the upsampling functions in DeadBeef interact with pipewire. Do you have any idea or know where I could look?

PipeWire should only resample when the audio sent by the player is in a different sampling rate. I am not familiar with deadbeef but as long as its output sampling rate matches the one in PipeWire only deadbeef's upsampling should be active.

[gorman42]

PipeWire should only resample when the audio sent by the player is in a different sampling rate. I am not familiar with deadbeef but as long as its output sampling rate matches the one in PipeWire only deadbeef's upsampling should be active.

Yeah, that's what I was expecting, due to my experience with foobar2000 on Windows. That appears not to be the case with DeadBeef.

There's two places in its settings where one can deal with samplerate. The one I would expect to work would be the DSP setting, where one can add a resampler (SRC). If one sets "Autodetect samplerate from output device", all is good. But the CPU usage stays the same (ie. it's not resampling). If one uses "Set samplerate directly" and sets it (in my case) to 176400... sound output becomes incredibly "slow". Something is clearly wrong, I will investigate with DeadBeef dev.

Thanks for all the help and for your program!

[servimo]

I have the same problem with resample in deadbeef, better leave resample as is, without it and leave the configuration of pipewire resample to what you want.