Use KDE for audio stuff?
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 194
- Joined: Mon Nov 13, 2017 5:54 am
- Has thanked: 8 times
- Been thanked: 4 times
Use KDE for audio stuff?
Hi,
I made some tests with xruncounter to optimize my system performance. I need my system for live-playing, so low latency + no xruns are a must.
On KDE, results are quite unpredictable: sometimes I get the first xrun at 95% load (which would be good, I think), sometimes at 60% or so.
If I use icewm instead (a very spartanic DE), results are much more stable.
I use linux-rt kernel on arch for both DEs, of course, performance governor, hyperthreading disabled.
Also, on KDE, when I look at the pianoteq performance monitor, the performance is fluctuating much more. On icewm, it is much smoother.
So my questions:
a) Shouldn't using the rt-kernel ensure that "normal" stuff doesn't get in the way of audio-stuff? That, even if KDE is doing something, this should be postphoned until the audio is processed?
b) Is it even possible to use a complex DE like KDE for audio stuff, or should I stick to a more simple one?
It is not possible for me to "cripple" KDE by switching off thousands of things, as this is my regular working machine, I need KDE fully functional. I would prefer to use it for audio, too, because I am used to it, but I would rather use a differend DE for audio than cripple KDE.
Thanks for your advice,
Andreas
I made some tests with xruncounter to optimize my system performance. I need my system for live-playing, so low latency + no xruns are a must.
On KDE, results are quite unpredictable: sometimes I get the first xrun at 95% load (which would be good, I think), sometimes at 60% or so.
If I use icewm instead (a very spartanic DE), results are much more stable.
I use linux-rt kernel on arch for both DEs, of course, performance governor, hyperthreading disabled.
Also, on KDE, when I look at the pianoteq performance monitor, the performance is fluctuating much more. On icewm, it is much smoother.
So my questions:
a) Shouldn't using the rt-kernel ensure that "normal" stuff doesn't get in the way of audio-stuff? That, even if KDE is doing something, this should be postphoned until the audio is processed?
b) Is it even possible to use a complex DE like KDE for audio stuff, or should I stick to a more simple one?
It is not possible for me to "cripple" KDE by switching off thousands of things, as this is my regular working machine, I need KDE fully functional. I would prefer to use it for audio, too, because I am used to it, but I would rather use a differend DE for audio than cripple KDE.
Thanks for your advice,
Andreas
-
- Established Member
- Posts: 194
- Joined: Mon Nov 13, 2017 5:54 am
- Has thanked: 8 times
- Been thanked: 4 times
Re: Use KDE for audio stuff?
Yes, but that's kde4. But I'll give it a try, baloo can easily be suspended, compositing is easy to switch off.
Thank you!
Thank you!
-
- Established Member
- Posts: 194
- Joined: Mon Nov 13, 2017 5:54 am
- Has thanked: 8 times
- Been thanked: 4 times
Re: Use KDE for audio stuff?
Hi,
I did a first test. While I did not see a real difference with xruncounter, the experience with pianoteq + performance-meter in pianoteq was now just as smooth (and completely xrun-free) as in icewm.
I have read all of the xruncounter - thread here, but I do not quite understand if this (quite nice) tool gives real-world results. My system usually gives the first xrun at about 70% (or even earlier), which would mean "very badly configured system".
I'll test with htop now.
I did a first test. While I did not see a real difference with xruncounter, the experience with pianoteq + performance-meter in pianoteq was now just as smooth (and completely xrun-free) as in icewm.
I have read all of the xruncounter - thread here, but I do not quite understand if this (quite nice) tool gives real-world results. My system usually gives the first xrun at about 70% (or even earlier), which would mean "very badly configured system".
I'll test with htop now.
-
- Established Member
- Posts: 194
- Joined: Mon Nov 13, 2017 5:54 am
- Has thanked: 8 times
- Been thanked: 4 times
Re: Use KDE for audio stuff?
Tests with htop reveal: All top-cpu processes are audio processes. Nothing really gets in the way (that can be seen with htop).
I summarize what I do on my system:
- use linux-rt kernel (which does not seem to make a real difference, at least as shown by xruncounter)
- set cpu governor to performance
- disable hyperthreading
- suspend baloo (with the command balooctl suspend )
- disable compositing
- disable kde power managemend
- set kde to plane-mode (this disables wlan + bluetooth)
- set realtime irq optimizations (rtirq start)
I use a behringer umc 1820 as soundcard, 64 bit buffer, 3 periods (qjackctl shows 4 ms latency, which is probably 8 ms roundtrip).
With this setting, everything seems to work smoothly. If I enable wlan, start a browser and play a hd video on that, I get xruns. But this does not come unexpectedly
Only disturbing thing is that xruncounter still gives the first xruns at about 70% - Of course, it would be nicer, if this was 98%.
The next stress test will be a real rehearsal with real musicians
Any more ideas?
I summarize what I do on my system:
- use linux-rt kernel (which does not seem to make a real difference, at least as shown by xruncounter)
- set cpu governor to performance
- disable hyperthreading
- suspend baloo (with the command balooctl suspend )
- disable compositing
- disable kde power managemend
- set kde to plane-mode (this disables wlan + bluetooth)
- set realtime irq optimizations (rtirq start)
I use a behringer umc 1820 as soundcard, 64 bit buffer, 3 periods (qjackctl shows 4 ms latency, which is probably 8 ms roundtrip).
With this setting, everything seems to work smoothly. If I enable wlan, start a browser and play a hd video on that, I get xruns. But this does not come unexpectedly
Only disturbing thing is that xruncounter still gives the first xruns at about 70% - Of course, it would be nicer, if this was 98%.
The next stress test will be a real rehearsal with real musicians
Any more ideas?
-
- Established Member
- Posts: 528
- Joined: Thu Sep 01, 2011 9:07 pm
- Has thanked: 86 times
- Been thanked: 23 times
Re: Use KDE for audio stuff?
I'm afraid I can't help, but if you'd like to try to run a light weight desktop that is very similar to KDE, try lxqt: https://lxqt.org/.
But I hope you can get it sorted with KDE.
But I hope you can get it sorted with KDE.
-
- Established Member
- Posts: 1392
- Joined: Thu Oct 11, 2018 4:13 pm
- Has thanked: 168 times
- Been thanked: 247 times
Re: Use KDE for audio stuff?
If you read the thread about xruncounter you may have seen that some USB interfaces perform better with a buffer of e.g. 96 frames at 48kHz.
How could the desktop environment affect audio performance? Taking a guess it may be the way the two different DEs handle USB e.g. does KDE constantly poll the USB bus to see if a removable drive has been inserted?
How could the desktop environment affect audio performance? Taking a guess it may be the way the two different DEs handle USB e.g. does KDE constantly poll the USB bus to see if a removable drive has been inserted?
- lilith
- Established Member
- Posts: 1698
- Joined: Fri May 27, 2016 11:41 pm
- Location: bLACK fOREST
- Has thanked: 117 times
- Been thanked: 57 times
- Contact:
-
- Established Member
- Posts: 194
- Joined: Mon Nov 13, 2017 5:54 am
- Has thanked: 8 times
- Been thanked: 4 times
Re: Use KDE for audio stuff?
The 96 bit buffer-tipp was spot on:
I posted 3 runs to show it's reproducible.
I had thought that most important was to have a latency that is a multiple of 1 ms, so I used 64 bit / 3 periods (4 ms latency). But 96 bit is still a very good latency with, as it seems, really good security regarding xruns.
Thank you!
(the above test was with kde running)
Code: Select all
[ag@agantergos ~]$ xruncounter
Samplerate 48000
Buffersize is 96
jack running with realtime priority
Xrun 1 at DSP load 99.449203
Xrun 2 at DSP load 99.449203
in complete 2 Xruns in 7154 circles
first Xrun happen at DSP load 99.449203 circle 7132
[ag@agantergos ~]$ xruncounter
Samplerate 48000
Buffersize is 96
jack running with realtime priority
Xrun 1 at DSP load 99.328026
Xrun 2 at DSP load 98.364014
Xrun 3 at DSP load 98.364014
in complete 3 Xruns in 7204 circles
first Xrun happen at DSP load 99.328026 circle 7159
[ag@agantergos ~]$ xruncounter
Samplerate 48000
Buffersize is 96
jack running with realtime priority
Xrun 1 at DSP load 98.457573
Xrun 2 at DSP load 98.457573
in complete 2 Xruns in 7103 circles
first Xrun happen at DSP load 98.457573 circle 7096
[ag@agantergos ~]$
I had thought that most important was to have a latency that is a multiple of 1 ms, so I used 64 bit / 3 periods (4 ms latency). But 96 bit is still a very good latency with, as it seems, really good security regarding xruns.
Thank you!
(the above test was with kde running)
-
- Established Member
- Posts: 2036
- Joined: Sat Jun 11, 2016 12:05 am
- Has thanked: 10 times
- Been thanked: 22 times
Re: Use KDE for audio stuff?
I haven't ran tests specifically for xruns, but I used Linux Mint KDE for many years and have recently switched to Xubuntu. The feeling on Xubuntu is that the OS operates quicker. There's also a sharpness to the display which resulted in not zooming so much plugins UIs. As for "adapatation": just about none. I miss nothing from KDE and rather enjoy the Xfce simplicity, really. Actually I do not know why I was sticking to KDE. Must be from habit.
Re: Use KDE for audio stuff?
Just a few comments.
No. I am no expert, but as far as I understand a RT kernel implements a particular kind of process scheduling. It has nothing to do specifically with the priority of audio processes. RT is not specifically for audio, in fact, but it is used also for industrial computers and in general all applications that have hard real-time requirements, that is, a certain operation must be performed within a given time window. You can assign higher/lower priority to any process you like with RT or any other kernel. The kind of kernel is more about how the queue of processes is handled.Musicteacher wrote:a) Shouldn't using the rt-kernel ensure that "normal" stuff doesn't get in the way of audio-stuff? That, even if KDE is doing something, this should be postphoned until the audio is processed?
I use GNOME 3, which to me feels much more responsive of Plasma, but it is actually a bloated mass. I am on Arch, and since recent changes in the kernel things have been running real well, much better than what I got used to. I cannot quite tell why, or how, but I am now fine with Arch Linux stock kernel and GNOME 3, which makes me think that you can get good performance with bloated DEs, although I do not quite know what actually did the trick few updates ago.Musicteacher wrote:b) Is it even possible to use a complex DE like KDE for audio stuff, or should I stick to a more simple one?
Last edited by CrocoDuck on Tue Apr 09, 2019 8:08 am, edited 1 time in total.
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Use KDE for audio stuff?
https://awesomewm.org/awesome is a highly configurable, next generation framework window manager for X. It is very fast, extensible and licensed under the GNU GPLv2 license.
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
-
- Established Member
- Posts: 381
- Joined: Sun May 28, 2017 3:52 pm
Re: Use KDE for audio stuff?
FWIW, the rt patch is mainly concerned with one thing, and that is lowering the kernel scheduling latency. That is to say that when a thread is supposed to be scheduled, this will happen sooner (less delay) than it would with a non rt kernel. It would lead to audio dropouts if it takes the kernel say 20ms to schedule your audio thread when the deadline is 2.9ms.Musicteacher wrote: a) Shouldn't using the rt-kernel ensure that "normal" stuff doesn't get in the way of audio-stuff? That, even if KDE is doing something, this should be postphoned until the audio is processed?
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
- Linuxmusician01
- Established Member
- Posts: 1524
- Joined: Mon Feb 23, 2015 2:38 pm
- Location: Holland
- Has thanked: 756 times
- Been thanked: 137 times
Re: Use KDE for audio stuff?
@Musicteacher (topic starter): what computer are you using? If Linux w/ KDE runs too slow then might you be using quite an old PC? In my experience Linux runs prettty fast and stable even with a very modest PC like mine. Only my Raspberry Pi needs LXDE to run close to acceptable instead of a modern full blown desktop environment like KDE, Gnome or Mate.
What are the specs of your computer?
What are the specs of your computer?