Do I really need an RT(Real Time) kernel

[wolftune]

Well, I'm happy to report that radeon does appear to be listed substantially lower than the USB port, even though they are both #18… Presently, I don't have the USB plugged in, but anyway, htop shows irq/18-ohci_hcd as -86 -85 and -84 (all in a row, I take it that is usb 4, 5, 6). Radeon is listed as irq 18 but it is down at -51

Anyway, your Mac reply referred to hardware, so if I installed GNU/Linux on the Mac, it would be similar, right? My overall point wasn't that any machine should do what another does, but that GNU/Linux as an OS is capable of what Mac OS does, given the same hardware…

Ok, so I'm getting more comfortable with the basic ideas, and I think I've got things working acceptably now… I'll see how it goes.

[wolftune]

Ok, so I thought I had everything, but it's still glitchy.

A question: should Jack be higher priority or lower than the audio interface? RIght now, Jack is higher.

Here's the situation: priorities in htop look good according to what I understand from advice here. I'm running low latency overall. I didn't actually set the CPU to performance nor turn off various things in the system, but I looked at system monitor and CPU was low. I'm getting perfect clear sound and no xruns most of the time, but then every two minutes or so there is a serious of 10-20 xruns all in quick succession. Then it goes back to clean. I tried to isolate something in system monitor, but all I noticed was that Xorg showed increased (but minor) activity right around when the xruns occur…

I have two goals here: one is to trouble shoot this and stop these little xrun bunches, the other goal is to understand the problem generally — such as know whether installing a low latency kernel would solve this in general…

Thanks again!

EDIT: Significant update: I tried some tests. I set a really high buffer (really high latency) and I didn't get any glitches. So high enough buffer does avoid the problem.

But I also tried a really low buffer and then tried loading as many effects as I could. I created feedback loops within plugins but I disconnected the output so I wouldn't hear that. I set the input channel directly to the output so I could hear myself. Result: thousands of xruns being registered constantly but I heard clean monitoring of myself through JACK! Yet I still heard a series of 10 or so glitches every few minutes. So the problem isn't xruns necessarily. The audible glitches always occur in conjunction with xruns, but lots of xruns are possible with no audible glitch. So something is happening every couple minutes that causes a short series of xruns and audible glitches, I think this is only at low or medium-low latency, but it seems completely unrelated to system load or to xruns necessarily.

Maybe this is entirely an issue with something sharing the thread with the interface? It really is predictable. It's every couple minutes, and it is one short burst of around 10-15 glitches along with xruns. Otherwise, all the settings I've done, thanks to your suggestions, seem to successfully allow all sorts of low latency processing and monitoring, but have no affect on this one regular glitch.

If I could just determine what is happening every couple minutes, I could maybe lower its priority or turn it off or something… maybe it is just some system check or hardware update or something??

For reference, I did get more audible glitches before enabling the RTIRQ stuff. It's just this one glitch that persists.

Finally, could settings like "no memory lock" or "unlock memory" or "soft mode" be worth trying? I thought about just testing them myself, but I'd appreciate advice.

[slowpick]

On my old dual-core, the difference in audio performance between qjackctl priority settings
of 70, and 89, is very obvious. This assumes /etc/security/limits.d has its priority set at 99.

I would also try using different combos of guitar software, a session with some calf-plugins,
another with rakarrack, then festige or wine with LePou and TSE plugins, or the free but excellent versions of
guitar rig 5 and amplitube 3

During live recording of multiple apps, the CPU load distibution on my setup wobbles around between 54/46 and 46/54,
which says that both cores are being engaged in meaningful ways, so hydrogen, yoshimi. rakarrack, timemachine
and the qjackctl setup, are all getting accounted for in desirable fashion.

A ancient dual-core with 2 Three ghz CPUs, bristling with pci slots, should be well under $200 at a recycler.

[slowpick]

Ok, so I thought I had everything, but it's still glitchy.

Finally, could settings like "no memory lock" or "unlock memory" or "soft mode" be worth trying? I thought about just testing them myself, but I'd appreciate advice.

Some items in the leftmost side of qjackctl are pretty obsolete for modern systems, except the rt setting.
But trying is temporary, so it won't hurt anything.

in the file /etc/security/limits.conf
@audio memlock should be set at unlimited, and @audio rtprio at 99

[wolftune]

slowpick, maybe you missed my edit update above? Or I edited after you posted, but I didn't realize it?
As I've been saying all along my issues have never had anything to do with CPU load. The machine I'm using is dual-core 2.5GHz. I know I could get something different that had pci slots, but I'm hoping I don't have to get a different computer and audio card just for this to work. Again, this has nothing to do with software choices, I can run all the effects I want and the problem doesn't get better or worse. (Although it is interesting that you are implying that guitar rig and amplitube work well under WINE! I am learning all the Linux software first, but I'm really glad that WINE works as well as it does).

EDIT: I almost posted this, but now I see how the system updates me that you just posted while I was typing. I apologize for my side in this confusion.
Ok, well, thanks for the help. I'll check that file.

Any idea what this every-couple-minutes glitch could be? Am I reasonable to guess it has something to do with some system hardware update or some other such setting? Is there some sort of process monitor that could identify it? I could wait until just when the glitch happens and check a log for that exact time…

[wolftune]

slowpick, according to this https://help.ubuntu.com/community/Ubuntu%20Studio%20Upgrade%20from%20Ubuntu
"Modyfying /etc/security/limits.conf should not be done on Ubuntu 10.04 and later"

Other info on that page indicated some automatic settings with other tools. Anyway, I did check that file and every line is commented out, so there's no active settings in that file. Maybe there should be, but I'm hesitant to fiddle with it now. I'll wait for further advice about whether and how I should actually do anything about this particular setting…

[Pablo]

"Modyfying /etc/security/limits.conf should not be done on Ubuntu 10.04 and later"

True.

I'll wait for further advice about whether and how I should actually do anything about this particular setting…

Do nothing. Or, to convince yourself, just take a look:

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

The fact is that the rtprio and memlock lines can be in /etc/security/limits.conf or in any file under the directory /etc/security/limits.d/. Nowadays, when jack is installed in your system (the jackd package) /etc/security/limits.d/audio.conf is written, so you only have to add yourself to the audio group in order to run jack in realtime mode.

You already belong to the audio group (double-check with this command: "groups"). Otherwise, jack couldn't be run in realtime mode. As you are seeing jack as a realtime process, you get that part right.

A question: should Jack be higher priority or lower than the audio interface? RIght now, Jack is higher.

I am not sure about the right priority for jack but I think that it should be just below the audio card (not in exact numbers as "90 then 89", but in position as "audio card, then jack and nothing in the middle"). Anyway, feel free to experiment and maybe share your experience

About the glitches: I suggest you open a new thread with this particular problem. This one is bloated and very few people is following by now, I guess.

Bluetooth and wireless are possibly to blame, but who knows. You can start by unloading those particular kernel modules (See lsmod to identify them and use sudo modprobe -r some_module. To reload, sudo modprobe some_module).

Another possible cause is what was already mentioned: Avoid CPU frequency scaling "on demand".

Probably, unbindig non-used usb buses in IRQ #18 would help too. Or a low-latency kernel. But try first the wireless and bluetooth modules unloading and the CPU freq scaling.

Cheers, Pablo

[wolftune]

Ok, I'll start a new topic once I have wrapped up here. I will just avoid wading into new tangents here.

For reference, I tried simply turning off the wireless (unchecking "enable wireless" in the network settings) and that didn't help. Also, this computer has no bluetooth. Is there a chance there is a bluetooth module running in the kernel even though there's no bluetooth hardware? If so, I definitely would want to kill that. Is turning off the wireless not enough to unload the module?

More will go in new topic. But thanks for everything already. I learned a lot here. And I think this topic will be useful for others to search and read in the future…

[slowpick]

slowpick, according to this https://help.ubuntu.com/community/Ubuntu%20Studio%20Upgrade%20from%20Ubuntu
"Modyfying /etc/security/limits.conf should not be done on Ubuntu 10.04 and later"

Other info on that page indicated some automatic settings with other tools. Anyway, I did check that file and every line is commented out, so there's no active settings in that file. Maybe there should be, but I'm hesitant to fiddle with it now. I'll wait for further advice about whether and how I should actually do anything about this particular setting…

ubuntu is always reinventing what works, to protect newbies from learning how to configure things,
bowing to the gates of microsoft

They implemented a system config utility of some sort to set up that file. Should be easy to find.
There may even be two files, one in a subfolder. Those lines should be active, at the settings I mentioned.
Old old news

[wolftune]

slow, as Pablo explained above, these settings are now implemented in other ways, and they are set in other files in other places. This stuff was adjusted by KXStudio and such upon install of JACK etc. and the behavior of my system indicates that the settings are correct. It isn't an issue of using a utility or not.
Anyway, I know you're being facetious, but I'll say that there's clearly still enough room to learn configuration stuff. And the main value of GNU/Linux is the capacity for control and freedom, not the necessity of configuring everything. The less choices that must be made, the better. Apple is a good model for human psychology by making decisions for the users rather than asking them their opinions about everything and giving hundreds of options. The problem is just when it comes to stopping users from changing things if they then choose to.

You should check out this:
http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html

And with that, I'll abandon this thread, and open new ones for ongoing issues. Good day.

[wolftune]

Boy, after all that, I've now got everything working great having turned off rtirq, basically undoing everything here.

Here's the short answer: install the proprietary vid-card driver, turn off networking, set cpufreq governor to performance, eliminate rtirq threading stuff I had tried before, use XRender instead of OpenGL for desktop effects, viola! buffer of 64 with lots of effects and no xruns or glitches!

Read more about my process of discovery at this other thread:
http://linuxmusicians.com/viewtopic.php?f=47&t=7989

I hope others can learn from my hassles…

[l0wt3ch]

You don't really need a realtime kernel. Just like you don't need a hot chick like this:



And yet, the appeal remains...

[wolftune]

While I personally can't turn off my base-level reaction to that picture , my intellect says, "hey, you're assuming everyone here is male (and heterosexual at that, or is a lesbian woman I guess). It may be true most computer types and therefore GNU/Linux users are guys, but we oughtn't reinforce that by emphasizing a guy's club sorta feel.

Anyway, I now have a low-latency kernel on KXStudio 12.04, and it works great, though I haven't done enough to scientifically compare it to the regular kernel.

[raboof]

While I personally can't turn off my base-level reaction to that picture , my intellect says, "hey, you're assuming everyone here is male (and heterosexual at that, or is a lesbian woman I guess).

Personally I thought it was a cutely hidden XKCD reference .

It may be true most computer types and therefore GNU/Linux users are guys, but we oughtn't reinforce that by emphasizing a guy's club sorta feel.

It almost goes without saying we welcome and respect participants of all genders, dispositions, races, etc etc etc on this forum.

While I agree this means it would be a good idea to keep the 'guy talk' to a minimum, I'm not moderating this away, as I suspect anyone who visits tech forums and is not part of the male/white/hetero/X stereotype will probably have seen enough not to take offense .

If anyone does take offense simply drop me a note and i'll fix it.

[raboof]

In this post,

RT Kernel. While I see it as a great need for certain musicians wanting to use the linux audio ecosystem live, it has very few benefits in a practical studio setup. It increases chance for XRuns and CPU usage

Do you really think the RT patches increase CPU usage and the chance of XRuns? Why? I'm not sure what exactly is still in the patchset - most of it indeed was already merged into mainline.