[SOLVED] rtirq "finer" tuning

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

[SOLVED] rtirq "finer" tuning

Post by CrocoDuck »

Hi there!

For USB audio profit, I have edited my /etc/conf.d/rtirq to this:

Code: Select all

# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc usb snd i8042"

# Highest priority.
RTIRQ_PRIO_HIGH=90

# Priority decrease step.
RTIRQ_PRIO_DECR=5

# Lowest priority.
RTIRQ_PRIO_LOW=51

and I am kinda fine with the results: I can play my guitar with Guitarix at 6-7 ms of round-trip latency, which is fine for "live" performances for me. I have to raise latency to record with Ardour, but Qtractor seems to do just fine. Anyway, I was reading this and by following to this link I saw that one can put strings of the kind "ehci_hcd:usb" at the RTIRQ_NAME_LIST field. By looking at dmseg after plugging - unplugging my Scarlett 2i4 into the USB 2 port I saw this:

Code: Select all

[  722.148183] usb 2-2: new low-speed USB device number 6 using xhci_hcd
while /usr/bin/rtirq status shows this:

Code: Select all

   99 FF      85   - 125  0.0 S    irq/23-ehci_hcd	
  101 FF      85   - 125  0.0 S    irq/45-xhci_hcd	
So I was thinking to raise priority for xhci with something like

Code: Select all

RTIRQ_NAME_LIST="rtc xhci_hcd:usb snd i8042"
however, it does not really seems to work: the internal sound card gets higher priority and the two fields above drop to the bottom. So... what I am not really understanding?
Last edited by CrocoDuck on Tue Feb 09, 2016 9:01 pm, edited 1 time in total.
Pablo
Established Member
Posts: 1274
Joined: Thu Apr 17, 2008 9:57 pm
Been thanked: 3 times

Re: rtirq "finer" tuning

Post by Pablo »

It works for me with "xhci"
RTIRQ_NAME_LIST="xhci"

Go figure (or ask Rui)
marosd
Established Member
Posts: 13
Joined: Mon Feb 08, 2016 1:37 pm

Re: rtirq "finer" tuning

Post by marosd »

Sorry, maybe its little bit off-topic but I dont want to start a new thread. I tried to change IRQ priority mentioned here:
http://subversion.ffado.org/wiki/IrqPriorities

command cat /proc/interrupts shows me my interrupts, but this command:

ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq"

shows me only a few IRQ's (no rtc0, no snd...), its BECAUSE I dont have the real-time kernel installed? I tried it on the generic linux kernel and the low-latency linux kernel.

Its important for me, because I cannot check IRQ priorities... THANK YOU very much.
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: rtirq "finer" tuning

Post by CrocoDuck »

Not sure it is the problem, but try to boot with threadirqs enabled. Open/etc/default/grub with your favourite editor (you need root permission to write changes on that file). Add threadirqs to GRUB_CMDLINE_LINUX:

Code: Select all

GRUB_CMDLINE_LINUX="other_options_that_were_here threadirqs"
Re-generate grub configuration:

Code: Select all

grub-mkconfig -o /boot/grub/grub.cfg
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: rtirq "finer" tuning

Post by gimmeapill »

Hi Croco,

Remove the other garbage, it's not needed anymore.
This should be enough, with no nasty side effect:

Code: Select all

RTIRQ_NAME_LIST="xhci_hcd:usb"
Edit: I need to recheck that syntax - I had it working but no access to my linux box, will confirm later

Also: xhci_hcd = usb3 -> good for most configs (despite popular wisdom).
Not sure if it has anything to do with usb2 vs usb3 bus performance, since we have anyway usb2 audio interfaces.
I suspect that this has more to do with isolating the audio interface on it's bus / driver...

Still... I think we miss something in order to tune rtirq properly - at least with recent kernels. All the documentation I found is outdated.
It is not as simple as raising the priority for xhci_hcd to the roof. I tried various configs and only managed to make performance worse.
In the end I gave up after realizing that the best results came by enabling threadirqs and leaving priorities alone (no rtirq on my system - I get roughly the same perf as you with my 2i2).

But if you find a way to outsmart the scheduler, I'd be interested to know about it ;-)
marosd
Established Member
Posts: 13
Joined: Mon Feb 08, 2016 1:37 pm

Re: rtirq "finer" tuning

Post by marosd »

CrocoDuck wrote:Not sure it is the problem, but try to boot with threadirqs enabled. Open/etc/default/grub with your favourite editor (you need root permission to write changes on that file). Add threadirqs to GRUB_CMDLINE_LINUX:

Code: Select all

GRUB_CMDLINE_LINUX="other_options_that_were_here threadirqs"
Re-generate grub configuration:

Code: Select all

grub-mkconfig -o /boot/grub/grub.cfg
Thanks, I will try it when I come home and I let you know. In my case I want (have) to an onboard soundcard (Realtek ALC887 codec) so I hope that latency will be lower than 10ms.
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: rtirq "finer" tuning

Post by CrocoDuck »

Cool. Thanks guys!
gimmeapill wrote:

Code: Select all

RTIRQ_NAME_LIST="xhci_hcd:usb"
This line seems to not be interpreted by rtirq. Instead, this one works:
Pablo wrote: RTIRQ_NAME_LIST="xhci"
After some experiments I found that this configuration satisfies me:

Code: Select all

# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc xhci snd"

# Highest priority.
RTIRQ_PRIO_HIGH=90

# Priority decrease step.
RTIRQ_PRIO_DECR=2

# Lowest priority.
RTIRQ_PRIO_LOW=51

snd is still there as I don't always use the external soundcard, so I am fine boosting the internal as well. Doesn't seem to me there is much difference between "rtc xhci snd" and "xhci". However, what that makes a massive difference is whether xhci has high priority or not. With xhci at 51 it is pretty much impossible to do stuff.
gimmeapill wrote: All the documentation I found is outdated.
Yeah... like referring to 2.6X kernels... how weird. It would be interesting to know how well all the pro-audio scripts and tricks we know apply to the newest kernels. I mean, the gain is evident in my system but I wonder whether much better things can be done on newer kernels... or if they are worse for some reason. I mean, the old distros like PureDyne, Tango Studio etc... had very good performances...

Anyway, I guess I can mark this as solved as I understood how to explicitly tell to rtirq to boost what I need.
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: [SOLVED] rtirq "finer" tuning

Post by gimmeapill »

Good to know, I need to try that again, then. Last time it was far from convincing...

I checked my system and this was working as well:

Code: Select all

RTIRQ_NAME_LIST="xhci_hcd"
But it's a bit hit or miss, depends how many processes you have with a similar name, it tries to catch the right one with wildcards apparently.
Regarding RTC you can remove for sure, it doesn't help anymore. See this answer from Rui:
http://www.rncbc.org/drupal/node/865.

Could you also list the priorities of the others threads? Jack + whatever you have running?
I think the answer lies in finding the right order, which may not necessarily be soundcard>Jack>application...
Last edited by gimmeapill on Wed Feb 10, 2016 8:26 pm, edited 1 time in total.
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: [SOLVED] rtirq "finer" tuning

Post by CrocoDuck »

gimmeapill wrote:See this answer from Rui:
http://www.rncbc.org/drupal/node/850.
Uh that thread is interesting. Rui also said:
rncbc wrote: there are only two special keywords: "snd" and "usb", which you know their meaning already; all other options might be sourced as a substring from what is found in the last and right-most column of the /proc/interrupts list.
and that pretty much explains to us how to build RTIRQ_NAME_LIST entries.

Here the situation with rtirq running as configured above:

Code: Select all

[crocoduck@arch ~]$ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r
     -  TS  2086  19   0 grep FF
    99  FF    34 139   - [posixcputmr/3]
    99  FF    31 139   - [migration/3]
    99  FF    30 139   - [watchdog/3]
    99  FF    27 139   - [posixcputmr/2]
    99  FF    24 139   - [migration/2]
    99  FF    23 139   - [watchdog/2]
    99  FF    20 139   - [posixcputmr/1]
    99  FF    17 139   - [migration/1]
    99  FF    16 139   - [watchdog/1]
    99  FF    15 139   - [watchdog/0]
    99  FF    14 139   - [migration/0]
    99  FF    12 139   - [posixcputmr/0]
    90  FF    71 130   - [irq/8-rtc0]
    88  FF   123 128   - [irq/46-xhci_hcd]
    87  FF  1800 127   - /usr/bin/jackd -P87 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB
    86  FF   255 126   - [irq/52-snd_hda_]
    86  FF   226 126   - [irq/48-snd_hda_]
    51  FF   250  91   - [irq/51-s-iwlwif]
    50  FF    69  90   - [irq/42-pciehp]
    50  FF    68  90   - [irq/44-PCIe PME]
    50  FF    67  90   - [irq/43-PCIe PME]
    50  FF    66  90   - [irq/42-PCIe PME]
    50  FF    49  90   - [irq/9-acpi]
    50  FF   434  90   - [irq/49-enp2s0]
    50  FF   249  90   - [irq/51-iwlwifi]
    50  FF   239  90   - [irq/50-i915]
    50  FF   218  90   - [irq/47-mei_me]
    50  FF   116  90   - [irq/45-0000:00:]
    50  FF   113  90   - [irq/1-i8042]
    50  FF   107  90   - [irq/23-ehci_hcd]
    50  FF   106  90   - [irq/12-i8042]
     1  FF     3  41   - [ksoftirqd/0]
     1  FF    33  41   - [ksoftirqd/3]
     1  FF    26  41   - [ksoftirqd/2]
     1  FF    19  41   - [ksoftirqd/1]
That jack setup is the lowest latency one (6-7 ms round-trip). It seems working just fine until I launch Ardour, which trows xruns at me for some reason. Here the situation with Ardour running:

Code: Select all

[crocoduck@arch ~]$ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r
     -  TS  2707  19   0 grep FF
     9  FF  2643  49   - /usr/lib/ardour4/ardour-4.6.0
    99  FF    34 139   - [posixcputmr/3]
    99  FF    31 139   - [migration/3]
    99  FF    30 139   - [watchdog/3]
    99  FF    27 139   - [posixcputmr/2]
    99  FF    24 139   - [migration/2]
    99  FF    23 139   - [watchdog/2]
    99  FF    20 139   - [posixcputmr/1]
    99  FF    17 139   - [migration/1]
    99  FF    16 139   - [watchdog/1]
    99  FF    15 139   - [watchdog/0]
    99  FF    14 139   - [migration/0]
    99  FF    12 139   - [posixcputmr/0]
    90  FF    71 130   - [irq/8-rtc0]
    88  FF   123 128   - [irq/46-xhci_hcd]
    87  FF  1800 127   - /usr/bin/jackd -P87 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB
    86  FF   255 126   - [irq/52-snd_hda_]
    86  FF   226 126   - [irq/48-snd_hda_]
    82  FF  2643 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  2643 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  2643 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  2643 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  2643 122   - /usr/lib/ardour4/ardour-4.6.0
    51  FF   250  91   - [irq/51-s-iwlwif]
    50  FF    69  90   - [irq/42-pciehp]
    50  FF    68  90   - [irq/44-PCIe PME]
    50  FF    67  90   - [irq/43-PCIe PME]
    50  FF    66  90   - [irq/42-PCIe PME]
    50  FF    49  90   - [irq/9-acpi]
    50  FF   434  90   - [irq/49-enp2s0]
    50  FF   249  90   - [irq/51-iwlwifi]
    50  FF   239  90   - [irq/50-i915]
    50  FF   218  90   - [irq/47-mei_me]
    50  FF   116  90   - [irq/45-0000:00:]
    50  FF   113  90   - [irq/1-i8042]
    50  FF   107  90   - [irq/23-ehci_hcd]
    50  FF   106  90   - [irq/12-i8042]
     1  FF     3  41   - [ksoftirqd/0]
     1  FF    33  41   - [ksoftirqd/3]
     1  FF    26  41   - [ksoftirqd/2]
     1  FF    19  41   - [ksoftirqd/1]


Here with Guitarix alone (working just fine):

Code: Select all

[crocoduck@arch ~]$ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r
     -  TS  2999  19   0 grep FF
    99  FF    34 139   - [posixcputmr/3]
    99  FF    31 139   - [migration/3]
    99  FF    30 139   - [watchdog/3]
    99  FF    27 139   - [posixcputmr/2]
    99  FF    24 139   - [migration/2]
    99  FF    23 139   - [watchdog/2]
    99  FF    20 139   - [posixcputmr/1]
    99  FF    17 139   - [migration/1]
    99  FF    16 139   - [watchdog/1]
    99  FF    15 139   - [watchdog/0]
    99  FF    14 139   - [migration/0]
    99  FF    12 139   - [posixcputmr/0]
    90  FF    71 130   - [irq/8-rtc0]
    88  FF   123 128   - [irq/46-xhci_hcd]
    87  FF  2776 127   - /usr/bin/jackd -P87 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB
    86  FF   255 126   - [irq/52-snd_hda_]
    86  FF   226 126   - [irq/48-snd_hda_]
    82  FF  2934 122   - guitarix
    82  FF  2934 122   - guitarix
    81  FF  2934 121   - guitarix
    51  FF   250  91   - [irq/51-s-iwlwif]
    50  FF    69  90   - [irq/42-pciehp]
    50  FF    68  90   - [irq/44-PCIe PME]
    50  FF    67  90   - [irq/43-PCIe PME]
    50  FF    66  90   - [irq/42-PCIe PME]
    50  FF    49  90   - [irq/9-acpi]
    50  FF   434  90   - [irq/49-enp2s0]
    50  FF   249  90   - [irq/51-iwlwifi]
    50  FF   239  90   - [irq/50-i915]
    50  FF   218  90   - [irq/47-mei_me]
    50  FF   116  90   - [irq/45-0000:00:]
    50  FF   113  90   - [irq/1-i8042]
    50  FF   107  90   - [irq/23-ehci_hcd]
    50  FF   106  90   - [irq/12-i8042]
     1  FF     3  41   - [ksoftirqd/0]
     1  FF    33  41   - [ksoftirqd/3]
     1  FF    26  41   - [ksoftirqd/2]
     1  FF    19  41   - [ksoftirqd/1]
And now Guitarix + Ardour (xruns frenzy):

Code: Select all

[crocoduck@arch ~]$ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r
     -  TS  3266  19   0 grep FF
     9  FF  3176  49   - /usr/lib/ardour4/ardour-4.6.0
    99  FF    34 139   - [posixcputmr/3]
    99  FF    31 139   - [migration/3]
    99  FF    30 139   - [watchdog/3]
    99  FF    27 139   - [posixcputmr/2]
    99  FF    24 139   - [migration/2]
    99  FF    23 139   - [watchdog/2]
    99  FF    20 139   - [posixcputmr/1]
    99  FF    17 139   - [migration/1]
    99  FF    16 139   - [watchdog/1]
    99  FF    15 139   - [watchdog/0]
    99  FF    14 139   - [migration/0]
    99  FF    12 139   - [posixcputmr/0]
    90  FF    71 130   - [irq/8-rtc0]
    88  FF   123 128   - [irq/46-xhci_hcd]
    87  FF  2776 127   - /usr/bin/jackd -P87 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB
    86  FF   255 126   - [irq/52-snd_hda_]
    86  FF   226 126   - [irq/48-snd_hda_]
    82  FF  3176 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  3176 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  3176 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  3176 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  3176 122   - /usr/lib/ardour4/ardour-4.6.0
    82  FF  2934 122   - guitarix
    82  FF  2934 122   - guitarix
    81  FF  2934 121   - guitarix
    51  FF   250  91   - [irq/51-s-iwlwif]
    50  FF    69  90   - [irq/42-pciehp]
    50  FF    68  90   - [irq/44-PCIe PME]
    50  FF    67  90   - [irq/43-PCIe PME]
    50  FF    66  90   - [irq/42-PCIe PME]
    50  FF    49  90   - [irq/9-acpi]
    50  FF   434  90   - [irq/49-enp2s0]
    50  FF   249  90   - [irq/51-iwlwifi]
    50  FF   239  90   - [irq/50-i915]
    50  FF   218  90   - [irq/47-mei_me]
    50  FF   116  90   - [irq/45-0000:00:]
    50  FF   113  90   - [irq/1-i8042]
    50  FF   107  90   - [irq/23-ehci_hcd]
    50  FF   106  90   - [irq/12-i8042]
     1  FF     3  41   - [ksoftirqd/0]
     1  FF    33  41   - [ksoftirqd/3]
     1  FF    26  41   - [ksoftirqd/2]
     1  FF    19  41   - [ksoftirqd/1]
By the way, I did not boost CPU freq or turned off internet. I guess it would help and I usually do it when recording stuff seriously. However, I would also try to achieve good performances without doing that. Seems weird to me that one has to kill stuff to do music in 2016. Especially with a very simple laptop:

Code: Select all

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 (rev e3)
00:1c.2 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1c.3 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #4 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
03:00.0 Network controller: Intel Corporation Wireless 3160 (rev 83)

Code: Select all

Bus 001 Device 002: ID 8087:8001 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 058f:3822 Alcor Micro Corp. 
Bus 002 Device 002: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 002 Device 004: ID 1235:800a Focusrite-Novation Scarlett 2i4
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
For now, the most stable - lowest latency setup is this one:

Code: Select all

/usr/bin/jackd -P87 -t5000 -dalsa -r96000 -p256 -n2 -D -Chw:USB -Phw:USB
Which yields to 16-17 ms of round-trip latency. Which isn't super bad really, but 10 ms above my mark.

EDIT:

cpu scaling and wireless turn-off do not improve the situation.

Code: Select all

cpupower frequency-set -g performance
modprobe -rv iwlmvm
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: [SOLVED] rtirq "finer" tuning

Post by gimmeapill »

Yeah, that's in line with what I found with my similar configuration: -r96000 -p64 -n3 is the lowest workable setting, but still far from perfect (depending on what you're doing). I didn't find either any magic rtirq/jackd/limits.conf combo.

Last try was the brute force method:
viewtopic.php?f=27&t=15042
It does seem to help a bit, but the drawbacks are hardly worth it for a regular system (unless you really love the sound of your fan).

There's still possibly some more stuff to explore
- cpu affinity, binding thread manually to a dedicated cpu core.
- playing with the priority of other system processes ('ksoftirqd' is on top of the list)
- changing the scheduler
- wait for the new upstream RT patchset (should be 4.4 if I'm not mistaken).

But frankly, at this stage, I think it has more to do with the application themselves: Guitarix and Hydrogen work absolutely fine at very low latencies.
The fat pigs (I mean full blown DAWs) not quite: qtractor seems to handle quite ok as long as you take it easy on the plugins. Ardour not so much, Renoise is workable without plugins but some specific actions will inevitably trigger an xrun. I didn't test the other complex applications.

The problem is then how to track down those potential thread priority / perf problems within the apps and raise useful bug reports (assuming that the application in question was ever supposed to run at 2ms latency - we're probably pushing the boundaries here).
The xruns reported by jackd do mention the faulty application, but beyond that go figure...

I did try to raise a question on the Renoise forums, and this resulted into an interesting discussion in which the main dev acknowledged that there might be room for improvement, but needed more data to identify the issues. Not so easy either, especially with closed source stuff. This won't be treated with high priority in any case - fair enough.

I got tired of shooting in the dark, so I'll start again when I understand better how to run a meaningful benchmark with cyclictest, just to avoid going through another lecture on system optimization.
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: [SOLVED] rtirq "finer" tuning

Post by CrocoDuck »

Yeah, I think that this is pretty much all I can do with the laptop really. And to be honest I am pretty pleased. I mean, it is not that I have a very lightweight setup. I am running a fully fledged GNOME3 + TLP for power saving. Hitting less than 20 ms of latency is good actually, I don't recall having experienced any better. It seems I can drop to 7 ms for my effects, so thumbs up, I can play live 8) ! Anyway, I am a compulsive guy and I would seriously love to be able to sit also my recording setup on 6 - 7 ms...
gimmeapill wrote: There's still possibly some more stuff to explore
- cpu affinity, binding thread manually to a dedicated cpu core.
- playing with the priority of other system processes ('ksoftirqd' is on top of the list)
- changing the scheduler
- wait for the new upstream RT patchset (should be 4.4 if I'm not mistaken).
Changing the scheduler to noop actually helped, so I guess that it is already optimized. I could add to the list:
- kill the bloody pulseaudio (dang, I forgot about it!)
- try to disable TLP (not a fan of this one. By the way, shouldn't be different from running on power supply).

I will report back.
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: [SOLVED] rtirq "finer" tuning

Post by gimmeapill »

And yet other ideas related to graphics: running a rootless xorg (or a wayland session),
Who know what could be the effects on the scheduler, thread priority - and overall latency.

We should almost compile a checklist and start a new thread...

Unfortunately I have no time to test anything at the moment (not even to play music actually :-()
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: [SOLVED] rtirq "finer" tuning

Post by CrocoDuck »

CrocoDuck reporting.

- Killing PulseAudio:

Code: Select all

systemctl --user mask pulseaudio.socket
pulseaudio --kill
It helps: xruns rate drops to ~4 xruns per minute while recording with Ardour on this setup:

Code: Select all

/usr/bin/jackd -P87 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB
Still not enough, but good stuff. I actually never wanted to install pulsaudio, but it is a dependency for GNOME and, well, skype, which I need. Interestingly, I cannot start pusaudio afterwards:

Code: Select all

systemctl --user unmask pulseaudio.socket
pulseaudio --start
The above fails.

-CPU affinity: I followed this. Seemed to not change the situation.

All the above plus performance cpu governor and suppressed wifi. Nothing changes.

I was running on battery the whole time. I will repeat on power supply (bypass energy saving) and note if any difference. I feel it is important to try to have the best performances ever on battery as well, as being "plug free" would be handy for many musicians at contest and similar I guess.
gimmeapill wrote: We should almost compile a checklist and start a new thread...
Yeah, I think. Every time I install Linux somewhere I have to go through the process of audio optimization. I think it would be nice to have an AUR package that at least installs the fundamental packages required for pro audio (pam, jack, rtirq...) and put in place sensible defaults. It would make the life easier, also considering that sometimes updates change things slightly. I guess it could be the output of such new thread... We could use this as a first base (it is there that I have learned about noop by the way).
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: [SOLVED] rtirq "finer" tuning

Post by CrocoDuck »

CrocoDuck reporting:

No advantages in disabling tlp and running on power supply:

Code: Select all

systemctl disable tlp
xurns per minute stable at 3-6.

The xrun per minute count living internet, ondemand governors, tlp and pusaudio active is more or less 10. So there is a difference indeed, but not so massive.

I think I pretty much reached the laptop full potential. I mean, I guess I could try to kill more stuff or install a "pro-audio" window manager (openbox maybe)... but I like my system versatile and "simple", so I guess I won't try it unless I am desperate for that 6-7ms while recording. I also want to believe that in 2016 we can have both pro audio and eye candy and background services. I mean, it is pretty much like that actually. I just want to see how much I can push the system. I will instead give a go to non stuff. They say it is lightweight...

I think I will start a thread soon regarding the pro-audio configuration check list.

EDIT:
non-timeline is pretty cool! No xruns with this when recording from all soundcard inputs:

Code: Select all

/usr/bin/jackd -P87 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB
None of the further optimizations (pulseaudio --kill, stop tlp, etc...) are in place. Stuff changes when adding guitarix. However, with my favorite guitarix preset the xurns count drops: 4-5 every 5 minutes. I already have a thing for the modularity and lightweight of non stuff.

It feels like it is more of a problem on the applications side. This laptop with openbox and non-daw would probably be the ultimate lowlatency workstation...
tramp
Established Member
Posts: 2328
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 450 times

Re: [SOLVED] rtirq "finer" tuning

Post by tramp »

CrocoDuck wrote:It feels like it is more of a problem on the applications side.
I don't think so.
Xrun's "every few seconds/minutes" indicate a kernel process which "steal" your CPU time,
because it is able to reach the highest possible priority.
In my case, on my mobo, it was the i2c_i801 module.
I get Xrun free, by disable it and choose carefully the right Kernel version.
I could use 3.4.104 or 4.1.12-rt13. All Kernels between fail to run Xrun free.

Forgot to mention, they fail because of a bug in the nouveau driver.
On the road again.
Post Reply