Problems with Bitwig performance

[tavasti]

Recently upgraded my computer, old was i7-4770 and new is AMD Ryzen 7 3700X. Bit more cores and bit better single core performance, but main point was moving from SFF to full size so I can have real gpu and more hdd. Old was running debian 11 based devuan, new debian 12 based.

For some reason, in new computer Bitwig is having hickups. It freezes durin playback/recording for short time, causing bunch of xruns. Jack itself runs ok, same time my guitar audio from interface to non-mixer and output works without any problems. There is no shortage of cpu, over 90% of cpu is idle. rtcqs only complaint is 'Kernel 6.6.12-1-liquorix-amd64 without 'threadirqs' parameter or real-time capabilities found' and meltdown mitigations. There is plenty of other programs running all the time, but closing them is last resort. My music making sessions can be sometimes very short, and if I would close all dozens of programs and then re-open them and put them to correct places in my multimonitor desktop would take some cases more time I am going to spend for making music.

Things done this far. All these seem to help a bit, but problem still exists

• change plugins in bitwig to run as separate process
• renice all other remarkable programs when making music
• renice -19 all bitwig processes

What else I could do?

[autostatic]

Something seems to get in the way of your audio processing. What interface are you using? And which audio backend? PW, JACK, Pipewire?

[tavasti]

Something seems to get in the way of your audio processing. What interface are you using? And which audio backend? PW, JACK, Pipewire?

Jack as backend, and audio interface is M-Audio Fast Track Ultra. But it is not the backend or interface, because in guitar sound there is nothing wrong, it is just Bitwig not getting its work done. Meybe I have to check out real-time priority, how to set that and if that could fix things

[autostatic]

Might be a try to add the threadirqs option to grub and give the IRQ thread of the USB bus to which your interface is connected priority. Maybe that would preempt the process that gets in the way of Bitwig.
Do you process your guitar signal or is it dry out that works fine?

[tavasti]

Might be a try to add the threadirqs option to grub and give the IRQ thread of the USB bus to which your interface is connected priority. Maybe that would preempt the process that gets in the way of Bitwig.

liquorix kernel does not have threadirqs. I have selected liquorix kernel in understanding that it would be better for audio work, but I don't know really. I could use other kernel. Normal kernel included in Devuan would be the default option, but I suspect it does not have more rt features built-in. This is with liquorix kernel:

Code: Select all

$ sudo chrt --max
SCHED_OTHER min/max priority	: 0/0
SCHED_FIFO min/max priority	: 1/99
SCHED_RR min/max priority	: 1/99
SCHED_BATCH min/max priority	: 0/0
SCHED_IDLE min/max priority	: 0/0
SCHED_DEADLINE not supported?

Do you process your guitar signal or is it dry out that works fine?

Guitar signal is coming in, passed to non-mixer for volume adjustment and then sent out.

[autostatic]

liquorix kernel does not have threadirqs.

It does. I'm running liquorix kernels with threadirqs and IRQ's are threaded:

Code: Select all

$ ps -eLo user,pid,cls,rtprio,cmd --sort rtprio | grep -E "[s]nd|[x]hci"
root         355  FF     50 [irq/62-xhci_hcd]
root         363  FF     50 [irq/64-xhci_hcd]
root         366  FF     50 [irq/66-xhci_hcd]
root         702  FF     50 [irq/91-snd_hda_intel:card10]
root         704  FF     85 [irq/92-snd_hda_intel:card11]
root         367  FF     90 [irq/68-xhci_hcd]

I have selected liquorix kernel in understanding that it would be better for audio work, but I don't know really. I could use other kernel. Normal kernel included in Devuan would be the default option, but I suspect it does not have more rt features built-in.

Not sure about the default Devuan kernel but it could very well have threaded IRQ's with the threadirqs option. If not you could try adding preempt=yes as a kernel option to give it more RT features. Or add both to check if you get threaded IRQ's then.

Guitar signal is coming in, passed to non-mixer for volume adjustment and then sent out.

Did you try with some processing? Like adding Guitarix or something similar? The current routing and processing of your guitar signal is in no way comparable to running a fully fledged DAW like Bitwig.

[oddy.o.lynx]

Are Pipewire, Wireplumber and Pulseaudio running in the background?

If they are I would recommend to mask them.

Code: Select all

systemctl --user mask pulseaudio
systemctl --user --now mask wireplumber.service
systemctl --user --now mask pipewire{,-pulse}.{socket,service}

Also this to test system config

https://codeberg.org/rtcqs/rtcqs

Preempt RT
==========
[ OK ] Kernel 6.6.12-1-liquorix-amd64 is using threaded IRQ's.

[tavasti]

liquorix kernel does not have threadirqs.

It does. I'm running liquorix kernels with threadirqs and IRQ's are threaded:

Code: Select all

$ ps -eLo user,pid,cls,rtprio,cmd --sort rtprio | grep -E "[s]nd|[x]hci"
root         355  FF     50 [irq/62-xhci_hcd]
root         363  FF     50 [irq/64-xhci_hcd]
root         366  FF     50 [irq/66-xhci_hcd]
root         702  FF     50 [irq/91-snd_hda_intel:card10]
root         704  FF     85 [irq/92-snd_hda_intel:card11]
root         367  FF     90 [irq/68-xhci_hcd]

Ok, rtcqs complains that it does not. Sure, it can depend what liquorix kernel.

Code: Select all

Linux hermo3 6.6.12-1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 6.6-16.2~bookworm (2024-01-17) x86_64 GNU/Linux

Did you try with some processing? Like adding Guitarix or something similar? The current routing and processing of your guitar signal is in no way comparable to running a fully fledged DAW like Bitwig.

Tried. Playing guitar thru guitarix works without problems, when bitwig gets stuck guitar signal thru guitarix works fine.

Are Pipewire, Wireplumber and Pulseaudio running in the background?

If they are I would recommend to mask them.

Pulseaudio is there, it has been in previous computer all the time, and if would kill that, then would need to kill all the other programs, and 15 minute session for making music would turn 15 minute session for closing programs and starting them and placing all windows back to their place. If guitarix works flawlessly, I doubt problem is in audio setup. Or have some idea why running pulseaudio would spoil only Bitwigs performance, leaving rest working ok?

Also this to test system config

https://codeberg.org/rtcqs/rtcqs

Preempt RT
==========
[ OK ] Kernel 6.6.12-1-liquorix-amd64 is using threaded IRQ's.

Like told in first post, rtcqs run is done. But yeah, now thinking, what message 'Kernel 6.6.12-1-liquorix-amd64 without 'threadirqs' parameter or real-time capabilities found' means? That kernel does not have that capability, or needs that argument on parameters? But still, jack performs ok, Bitwig is the one that does not perform?

[tavasti]

Added threadirqs to kernel command line, and situation is same.

[autostatic]

Adding threadirqs itself doesn't improve anything. After adding it you can take advantage of the threaded IRQ's created by this kernel option by prioritising them. You can use rtirq or udev-rtirq for that.

[Impostor]

Adding threadirqs itself doesn't improve anything. After adding it you can take advantage of the threaded IRQ's created by this kernel option by prioritising them. You can use rtirq or udev-rtirq for that.

Is threading IRQ's also applicable to onboard sound chips? Or is that only relevant for audio interfaces?

[autostatic]

It also applies to onboard audio, see my earlier post:

Code: Select all

$ ps -eLo user,pid,cls,rtprio,cmd --sort rtprio | grep -E "[s]nd|[x]hci"
root         355  FF     50 [irq/62-xhci_hcd]
root         363  FF     50 [irq/64-xhci_hcd]
root         366  FF     50 [irq/66-xhci_hcd]
root         702  FF     50 [irq/91-snd_hda_intel:card10]
root         704  FF     85 [irq/92-snd_hda_intel:card11]
root         367  FF     90 [irq/68-xhci_hcd]

The IRQ of the onboard audio (irq/92-snd_hda_intel:card11) gets a rtprio of 85.

[merlyn]

If I understand correctly, all was good with Bitwig on your old Intel machine?

Something I would be curious about is -- do you have amd microcode installed? I'm using a Ryzen chip with Arch, and things have improved as I've updated the system. Debian is stricter about what's free and what's not than Arch. amd microcode is not free, so it may not come with Debian, in fact I don't think it would.

On Arch the package is called amd-ucode 20240115.9b6d0b08-1 which I would assume is the date 15th Jan 2024.

[tavasti]

If I understand correctly, all was good with Bitwig on your old Intel machine?

Yeah, or at least xruns were not happening all the time.

Something I would be curious about is -- do you have amd microcode installed? I'm using a Ryzen chip with Arch, and things have improved as I've updated the system. Debian is stricter about what's free and what's not than Arch. amd microcode is not free, so it may not come with Debian, in fact I don't think it would.

Good question, but I suppose even that was bummer, I seem to have package amd64-microcode, 'Processor microcode firmware for AMD CPUs'

[merlyn]

A Ryzen 3700x is much more powerful than an Intel 4770. You should be getting better performance. There's the software and configuration side, where you could try rtirq.

There's the hardware side, where you could have a look at the BIOS. I have an MSI motherboard and in the BIOS there are one click options to basically safely overclock the CPU and memory. The memory overclocking is called 'XMP' and the CPU overclocking is called 'Creator Genie'. Different manufacturers will have different names. You can at least see if 'PBO' is on, which is AMD's version of Turbo Boost.