Skip the ISO and focus on documentation?

Official support for the KXStudio Linux distribution and applications.
More info at http://kxstudio.linuxaudio.org/

Moderators: falkTX, khz, MattKingUSA

What should the focus be on?

Finish KDE5/Neon based ISO and make it as nice experience as possible.
18
33%
Skip the ISO, instead document and fix general issues with most common desktops
37
67%
 
Total votes: 55

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: Skip the ISO and focus on documentation?

Postby asbak » Sat Nov 24, 2018 4:14 pm

In Linux kernels 3.0 and later, many of the additionally required realtime patches have been incorporated as standard. For those who are recording Audio, a standard non-realtime kernel may be sufficient for your needs, and running Jack with a non realtime kernel will work fine.


Adhering to poorly worded documentation like this is what got us into this mess in the first place. Yeah, audio will work with a standard kernel and no tuning and you can even record, but so what?

The last time I checked this forums's fqdn was "linuxmusicians". Trust me, no musician wants to deal with under-performing, xrunning and laggy audio hardware and the quoted wisdom imparted above will guarantee you exactly that - rubbish audio performance.

The documentation needs to be re-written to make it specific, accurate and relevant and to put an end to the masses of disinformation out there which isn't doing the Linux audio cause any favours.

User avatar
CrocoDuck
Established Member
Posts: 1029
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: Skip the ISO and focus on documentation?

Postby CrocoDuck » Sat Nov 24, 2018 5:53 pm

asbak wrote:Adhering to poorly worded documentation like this is what got us into this mess in the first place. Yeah, audio will work with a standard kernel and no tuning and you can even record, but so what?


If bad, outdated, documentation is what you are complaining about, than I would suggest to double check few of your statements:

asbak wrote:- Standard kernels suck for low-latency audio
- A PREEMPT or low latency kernel is highly recommended and WILL outperform a standard kernel and works great for general purpose use and is easy to install


A low latency kernel is a standard kernel compiled by selecting appropriate parameters at compilation time. A RT kernel is also patched, so it is not a standard kernel. At some point the RT patch will be included in the standard tree, so one will be able to select the RT preemption model at compile time, without patching. RT will become a feature of the standard kernel. What is reported by khz is in essence correct information, as whatever parameters you choose to compile a standard kernel with, you get a standard kernel out unless you apply patches too. Beside, I do not understand the confrontational tone, since it proves your point that in most cases RT is not necessary. On this note:

Whilst I agree that documentation is old in many places, and a lot of outdated popular wisdom circulates from years back when things worked differently, I don't understand the arrogance by which you expose your points. You can be right also by not being so confrontational. This is a comment about the language you chosen, not about you as a person. I believe it will help you having a constructive exchange in a public forum if you choose to use a language that doesn't sound that abrasive. Just my humble tip. Take it or leave it.

asbak wrote:The documentation needs to be re-written to make it specific, accurate and relevant and to put an end to the masses of disinformation out there which isn't doing the Linux audio cause any favours.


I am myself guilty of not experimenting enough, study enough, and contribute to the documentation but please, unless you are already doing so, if you have adequate reproducible evidence about what kind of configuration is effective, and about what bits of information are outdated, then contribute to the documentation.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

Jack Winter
Established Member
Posts: 376
Joined: Sun May 28, 2017 3:52 pm

Re: Skip the ISO and focus on documentation?

Postby Jack Winter » Sat Nov 24, 2018 8:00 pm

The same could be said for vocal proponents of the lowlatency kernel :)

I guess once it's just another kernel config option we can argue whether PREEMPT or PREEMPT RT is the better choice. One fact is that PREEMPT RT has lower kernel scheduling latency, whether that is important or not probably is a YMMV. On some distros it's just another package to install, on Debian though it appears more involved to install one.

I've maintained a rt kernel for many years on Archlinux. I am not aware of users having any problems specific to the use of the rt kernel. I do know that if you use it with nvidia without adding a patch it will lock up the gpu and you'll have to reboot to recover the system. I've also occasionally heard of users having issues with the nouveau driver too.

My opinion is to try the low latency kernel first, and if you still have xruns, then try the rt kernel. If xruns persist then you might want to troubleshoot the system using various tools, most of them included in the rt-tools package.
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 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

Jack Winter
Established Member
Posts: 376
Joined: Sun May 28, 2017 3:52 pm

Re: Skip the ISO and focus on documentation?

Postby Jack Winter » Sat Nov 24, 2018 8:53 pm

Here is my take on what's needed for a good low latency system.

1. Hardware that doesn't cause problems, e.g. motherboards without SMIs, peripherals that don't have a driver causing high peaks in kernel scheduling latency, etc.

2. A lowlatency or realtime kernel.

3. Interrupt handlers exported as threads, and the one handling the soundcard set to a really high priority.

4. The right priority level set for JACK's or the app's audio threads.

5. When dealing with USB, try to avoid many devices connected to the same root hub, use good cables, don't use an external hub, etc.
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 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: Skip the ISO and focus on documentation?

Postby asbak » Sun Nov 25, 2018 9:32 am

CrocoDuck wrote:If bad, outdated, documentation is what you are complaining about, than I would suggest to double check few of your statements:
A low latency kernel is a standard kernel compiled by selecting appropriate parameters at compilation time.


Stop being pedantic.


Most users will assume that what's supplied out of the box with 9 out of 10 distros is a "standard" release with a "standard" kernel. Not a PREEMPT kernel which they'll need to install themselves whether through compilation or package. Distros usually don't install out of the box with a PREEMPT compiled kernel.

In Linux kernels 3.0 and later, many of the additionally required realtime patches have been incorporated as standard. For those who are recording Audio, a standard non-realtime kernel may be sufficient for your needs, and running Jack with a non realtime kernel will work fine.


^ Documentation worded like this which is endlessly quoted as "proof" is unhelpful because it focuses on one use case scenario namely recording.

Most readers including many regular users (this thread is living proof) then descend into groupthink mode and misinterpret these instructions dealing with a recording example only (and dealing with usage case scenarios where the user doesn't care about his awfully performing high latency audio system) to mean that it applies universally, case closed, problem fixed.

Then users come back (time and time and time again) and beg for help because they cannot understand why they're getting so many xruns with low-latency settings because the "experts" on this forum and the documentation keep telling them that a "standard kernel is all they need to use jack!"

I mean.... WTF??????

People (you know who you are), this kind of circular un-logic is infuriating and you really, really need to stop putting out bad advice and blindly quote documentation you don't understand and have no experience with.

I already conceded the point on RT Kernels and agree that if they work reliably on your particular system then they'll offer better performance than a PREEMPT kernel. From what I've observed there didn't seem to be a huge difference (I didn't have a way to measure it) between a PREEMPT and a RT kernel. However, there is a huge difference between a "standard" OOTB non-PREEMPT (and don't start on me with pedantic smart-ass arguments about it please) and a PREEMPT kernel.

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: Skip the ISO and focus on documentation?

Postby asbak » Sun Nov 25, 2018 9:37 am

Jack Winter wrote:Here is my take on what's needed for a good low latency system.

1. Hardware that doesn't cause problems, e.g. motherboards without SMIs, peripherals that don't have a driver causing high peaks in kernel scheduling latency, etc.

2. A lowlatency or realtime kernel.

3. Interrupt handlers exported as threads, and the one handling the soundcard set to a really high priority.

4. The right priority level set for JACK's or the app's audio threads.

5. When dealing with USB, try to avoid many devices connected to the same root hub, use good cables, don't use an external hub, etc.


That's good advice

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: Skip the ISO and focus on documentation?

Postby asbak » Sun Nov 25, 2018 10:38 am

+ avoid heavy duty desktops laden with bells and whistles
+ check what kind of scheduled jobs are set up and when they'll execute and disable ones which may cause issues
+ set qjackctl priority (or in jackd) to around 89 or more
+ set CPU to Performance Mode (instead of powersaving) to reduce xrunning when doing audio work
+ Sort out a audio group and limits files and pam

Create an audio group

Code: Select all

sudo groupadd audio


Add your user account to the audio group

Code: Select all

sudo usermod -a -G audio <your user account>


Edit limits and add these lines, then reboot

/etc/security/limits.conf

Code: Select all

@audio - rtprio 90
@audio - memlock unlimited
<your user account>     soft    nofile           100000
<your user account>    hard    nofile           100000


/etc/security/limits.d/audio.conf

Code: Select all

@audio   -  memlock    unlimited
@audio   -  rtprio     90


/etc/pam.d/common-session

Code: Select all

session required pam_limits.so

User avatar
CrocoDuck
Established Member
Posts: 1029
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: Skip the ISO and focus on documentation?

Postby CrocoDuck » Sun Nov 25, 2018 10:51 am

asbak wrote:Stop being pedantic.


Most users will assume that what's supplied out of the box with 9 out of 10 distros is a "standard" release with a "standard" kernel. Not a PREEMPT kernel which they'll need to install themselves whether through compilation or package. Distros usually don't install out of the box with a PREEMPT compiled kernel.


So, you are against spreading misinformation and -at the same time- you want to pander to point of view of most users regardless of how inaccurate that could be. That is contradiction right there. Anyway, most people not using Debian/Ubuntu have to build a lowlatency kernel from source. See Open Suse as an example: viewtopic.php?t=15655. What you describe is maybe 9/10 of users, not 9/10 of distributions, and I am not even that sure about that.

That's it from me on the topic. We all agree that the best way to configure your system is step by step, as Jack Winter summed up nicely, and I still do not understand your need for abrasive confrontational language, especially when we agree 95%. But if that's your style, please go ahead.

Signing off.
Last edited by CrocoDuck on Sun Nov 25, 2018 11:50 am, edited 1 time in total.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

Jack Winter
Established Member
Posts: 376
Joined: Sun May 28, 2017 3:52 pm

Re: Skip the ISO and focus on documentation?

Postby Jack Winter » Sun Nov 25, 2018 11:40 am

I'm not convinced that DEs or background processes are relevant at all, at least on modern machines (but I've been running realtime kernels for years and am not really familiar with how the lowlatency kernel works in the real world). IMO if the system is set up properly the audio threads ought to be running with a higher priority thus preempting everything else running on the system.

Soundcard interrupt handling thread at say 95 and JACK or (the applications audio threads lower say at 80) ought to be a good starting point.

Regarding CPU powersaving, it appears to me to be another YMMV. Some CPUs seem to create no problem at all when switching between sleep states, while others do indeed benefit from being in performance mode. There is also the /dev/cpu_dma_latency interface which can be used to disable deeper sleep states on certain CPUs.

Using the audio group for realtime related PAM configuration might not always be the best solution. For instance it breaks per seat access to soundcards and would in some circumstances be frowned on. On Archlinux we changed to using a realtime group instead. This as the ability to use realtime threads or to memlock really is orthogonal to accessing soundcards. One can conceive of users wanting to use realtime threads while not being interested in audio at all.

In fact there is no need to use a group at all when configuring PAM, one could just use an asterix '*' (all users) or the username in limits.conf.

Something like:

Code: Select all

* - memlock unlimited
* - rtprio 98


or

Code: Select all

username - memlock unlimited
username - rtprio 98


And yes, it's probably a good idea to up the amount of file handles too.
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 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: Skip the ISO and focus on documentation?

Postby asbak » Sun Nov 25, 2018 2:59 pm

CrocoDuck wrote:So, you are against spreading misinformation and -at the same time- you want to pander to point of view of most users regardless of how inaccurate that could be. That is contradiction right there.


A low latency kernel is a standard kernel compiled by selecting appropriate parameters at compilation time.


You can extend your argument and claim that a RT kernel is a standard kernel with a small patch applied & appropriate parameters selected at compilation time. Therefore all kernels incl. RT kernels are standard kernels. That kind of logic. I disagree with your claim and from my point of view you are bickering about and hiding behind semantics and fail to address the actual issue.

An out of the box distro usually doesn't provide a preempt or RT kernel, and the kernel it does provide sucks for use with low-latency audio. If you choose to disbelieve this then do so at your own cost. The truth in my claims are easily verifiable by anybody who could be bothered to install a new system and testing the before and after results for themselves. The information contained therein is nothing new, merely a variation on what's already in countless (yet amazingly overlooked by most people) configuration guides dealing with this very issue.

The documentation being touted that claims that "all you need to use jack and record is a standard kernel" does not take into account that not everybody out there wants to be forced to have to set high latency on their soundcards to avoid xruns. One could enter a donkey into a thoroughbred horse race. Would the donkey run? Sure the donkey would run and it would be a joke. High latency is very undesirable to most musicians. This forum is called "linuxmusicians" is it not?

Why am I being abrasive? Because after a while it gets old having to correct the same fisherman's tales and misinformation by people who have no idea what they're talking about and who insist on arguing about it instead of testing the results for themselves first.

User avatar
khz
Established Member
Posts: 1054
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Skip the ISO and focus on documentation?

Postby khz » Sun Nov 25, 2018 8:45 pm

@asbak Understanding question: If an RT kernel is not recommended, why do you recommend the limits.conf entries for a standard kernel and why do the limits.conf entries do what for a standard kernel if the standard kernel would not already contain elements of the RT kernel?
Or are the limits.conf entries something else and the "rtprio - max realtime priority" just means "realtime priority" for fun and has nothing to do with realtime? And what is the effect of the entry and above all: why?

Are the kernel logs obsolete?

CrocoDuck wrote:I am myself guilty of not experimenting enough, study enough, and contribute to the documentation but please, unless you are already doing so, if you have adequate reproducible evidence about what kind of configuration is effective, and about what bits of information are outdated, then contribute to the documentation.

fullack or new speech :like:
FZ - Does humor belongs in Music?
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.

User avatar
raboof
Established Member
Posts: 1609
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Contact:

Re: Skip the ISO and focus on documentation?

Postby raboof » Mon Nov 26, 2018 8:18 am

Good discussion here - let's all remember to keep it friendly and fun for everyone!

millerthegorilla
Established Member
Posts: 59
Joined: Wed Oct 26, 2011 11:22 am

Re: Skip the ISO and focus on documentation?

Postby millerthegorilla » Thu Mar 07, 2019 10:46 am

Perhaps falktx and the team might consider using flatpaks at some point in the future, which would mean portability across all the desktop environments.


Return to “KXStudio Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests