Page 7 of 9

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 7:28 am
by gimmeapill
A few shots in the dark here, after looking at your pastebin:
- rtkit is abandoned for 5 years and running at RTprio 99, right in the danger zone. I wouldn't trust that nowadays, maybe it interferes with things that are now better done by the kernel. Did you try disabling it?
- Is IRQ threading even working? I can't find your audio interfaces either
- 3d acceleration: the scrolling and xruns thing is quite symptomatic of a graphic driver issue

Apologies for being a bit vague, this is posted from work before the second coffee;-)

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 9:34 am
by lilith
gimmeapill wrote:A few shots in the dark here, after looking at your pastebin:
- rtkit is abandoned for 5 years and running at RTprio 99, right in the danger zone. I wouldn't trust that nowadays, maybe it interferes with things that are now better done by the kernel. Did you try disabling it?
- Is IRQ threading even working? I can't find your audio interfaces either
- 3d acceleration: the scrolling and xruns thing is quite symptomatic of a graphic driver issue

Apologies for being a bit vague, this is posted from work before the second coffee;-)


Hi,

thanks for the points. I will see if I can can disable the rtkit. I googled a little bit and it only seems to be used by Pulseaudio.
Concerning the IRQ treading: How can I check if it working or not? Should it appear in the list as a RT process when executing?:

Code: Select all

ps ax -T --format uname,pid,lwp,ppid,pri,rtprio,cmd


The scrolling issue is worst in Firefox and Chromium. When I scroll within the DAW there´s no problem.

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 10:01 am
by gimmeapill
Ah, yes, rtkit is a dependency of pulseaudio, probably better not touch it then.

For the IRQ threads:yes you should see them in the process list (I usually check with htop).
The behavior of RT kernels is to have it enabled by default, if not you can use the "threadirqs" boot parameter.

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 10:04 am
by merlyn
What does

Code: Select all

grep threadirqs /proc/cmdline
say?

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 11:55 am
by lilith
merlyn wrote:What does

Code: Select all

grep threadirqs /proc/cmdline
say?


I´ll take a look in the evening again. I wonder that gaphical processes can cause xruns or even opening the browser, as these processes are not running with RT priority. On the other hand I can run heckbench to bring the CPU load to 90% and I don´t get any xruns, but just opening the bowser causes xruns while the CPU is shortly increasing to 80% or so.

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 12:04 pm
by raboof
lilith wrote:I can run heckbench to bring the CPU load to 90% and I don´t get any xruns, but just opening the bowser causes xruns while the CPU is shortly increasing to 80% or so.

I think someone already mentioned perhaps this may be related to your video driver or video acceleration, or perhaps networking stack - it would be interesting to see if the same problem happens when you disable networking or use simpler video driver.

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 12:37 pm
by lilith
raboof wrote:
lilith wrote:I can run heckbench to bring the CPU load to 90% and I don´t get any xruns, but just opening the bowser causes xruns while the CPU is shortly increasing to 80% or so.

I think someone already mentioned perhaps this may be related to your video driver or video acceleration, or perhaps networking stack - it would be interesting to see if the same problem happens when you disable networking or use simpler video driver.


I can do the network test (it´s connected via LAN, not WLAN), but I think I already use the simplest video driver,, i.e. i915 kernel driver for my onboard graphic chip. I think vesa would be even more simple, but I need the compton compositor for Renoise. Without compton I get an extreme load of xruns in Renoise, which is somehow related to how Renoise is drawing its GUI.

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 12:51 pm
by gimmeapill
Without compton I get an extreme load of xruns in Renoise, which is somehow related to how Renoise is drawing its GUI.


That is even weirder, you shouldn't need a compositor to run Renoise, it is the leanest thing around.
(I have no problem using it as a DAW with Guitarix at 2-3 ms latency on a 5y old notebook, but I'm on fluxbox and not using any plugins in that config).

Anyway, this really points at something with your graphic stack.
I see you're on xfce with lightdm as session manager: could you try something really light, like icewm, or any minimal WM (fluxbox, Wmaker etc...) - just to confirm the behavior is the same?

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 1:07 pm
by lilith
gimmeapill wrote:
Without compton I get an extreme load of xruns in Renoise, which is somehow related to how Renoise is drawing its GUI.


That is even weirder, you shouldn't need a compositor to run Renoise, it is the leanest thing around.
(I have no problem using it as a DAW with Guitarix at 2-3 ms latency on a 5y old notebook, but I'm on fluxbox and not using any plugins in that config).

Anyway, this really points at something with your graphic stack.
I see you're on xfce with lightdm as session manager: could you try something really light, like icewm, or any minimal WM (fluxbox, Wmaker etc...) - just to confirm the behavior is the same?


I can try that, if it helps. If you are interested: The problem is described here: https://forum.renoise.com/t/bad-perform ... inux/56770
It seems to be a bug with Mesa 13 that is still used by Debian 9. Could it be better with a different session manager then?

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 1:44 pm
by gimmeapill
Nice one, even Taktik doesn't have a clue ;-)

I wouldn't bet on the session manager, I was just meaning to install a minimal window manager and test the performance (after making sure all xfce related stuff is not running - preferably after reboot).
This is the easiest thing to try without screwing up your configuration.
But if you have a doubt, just try with startx /xinit, maybe this change something after all.

If is really a problem with the mesa version, then you're probably better off moving straight to Buster/Testing rather than using backports.
It should be *reasonably safe* at this point in time since the release is just 2-3 months away...

In any case, I don't think it is worth spending time on minor optimization settings before you get this one sorted out...

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 2:25 pm
by lilith
Thanks, I will look what startx /xinit is doing. I assume it will load a different window manager on the fly, never did this though. I can also wait for 3 months more and then move to Buster or maybe MXLinux, which also looks good.

gimmeapill wrote:Nice one, even Taktik doesn't have a clue ;-)

I wouldn't bet on the session manager, I was just meaning to install a minimal window manager and test the performance (after making sure all xfce related stuff is not running - preferably after reboot).
This is the easiest thing to try without screwing up your configuration.
But if you have a doubt, just try with startx /xinit, maybe this change something after all.

If is really a problem with the mesa version, then you're probably better off moving straight to Buster/Testing rather than using backports.
It should be *reasonably safe* at this point in time since the release is just 2-3 months away...

In any case, I don't think it is worth spending time on minor optimization settings before you get this one sorted out...

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 3:09 pm
by khz
@minimal_window_manager Awesome is super or Fluxbox, WindowMaker.
But non-free graphics drivers are also important. IMHO

Also:
# If a hardware component is obsolete (for example CPU/GPU/...) and the desired program requires new/more technology/performance, the computer/operating system may experience problems. You can do magic with Linux, but you can't improve the hardware.
Use good hardware. :-)

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 3:47 pm
by khz
Why don't you install another distribution and adapt it to your audio? It may be that the hardware/software problems are a Debian problem. Debian is rather conservative. *duck&run* ;-)

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 3:52 pm
by lilith
khz wrote:Why don't you install another distribution and adapt it to your audio? It may be that the hardware/software problems are a Debian problem. Debian is rather conservative. *duck&run* ;-)


I thought it´s fine because someone (some linux geek) suggested to take Debian :mrgreen: But maybe in the end it´s really better to make a new installation. I will try if it works with a MXLinux Livestick.

Re: Standard test needed to benchmark XRUNs

Posted: Fri May 03, 2019 4:12 pm
by khz
Debian is just so ingenious because it is conservative or rather consistent. That made the description easier for me. It's about understanding and learning. I also like Debian as a distribution, next to Gentoo. But I also wrote "Installation of a distribution, for example Debian:".

Use the distribution that you personally like best and supports your hardware best as well as providing the software dependencies/needs best.

cheers,
8) Freedom 8)