LinuxMusicians

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.

wolftune wrote: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 .

wolftune wrote: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.

In this post,

i2productions wrote: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.

She's almost a thread zombie I can also verify she's never worked at
a Guitar Center within a 500 mile radius of my shack.

Back to business, bfs is another kernel alternative, and works very well
for audio production, and probably other media tasks.

raboof wrote: 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.

I haven't tested any of the recent RT kernels but in the past I have tested generic vs. RT. While the increase in CPU usage is likely negligable, it did amout to around 2% extra CPU usage. That becomes compounded by driving your latency as low as you can go with it. I also tested sequencing and mixing the same song in ardour RT vs generic and I ended up with a dozen more Xruns using the RT kernel at the same sample rate and buffer size. Small issues, but still it led me to believe that the RT kernel isn't neccesary if not using it for a live setup. And since most of it has been merged into generic kernel's it seems rather unnecessary.

I'm no expert, but shouldn't this discussion, if we're going to have it now, in light of the latest kernels, emphasize low-latency in addition to RT? I am under the distinct impression that low-latency kernel is the recommended choice these days…

wolftune wrote: in light of the latest kernels, emphasize low-latency in addition to RT? I am under the distinct impression that low-latency kernel is the recommended choice these days…

I think you're on to something...

"The main goal in audio-processing is the latency. The latency is the delay between signal-creating and reaching the processing in the system (e.g time between pressing a key on the keyboard and hearing the tone). The standard kernels have the disadvantage that the processing is slower (~11ms) than in Windows or on a MAC . The faster the system, i.e. the lower the latency, the more things can happen simultaneously on a the system (e.g. more synths...) Ingo Molnar, a RedHat developer and some others have started a project to minimize the latency in Linux: Realtime Preemption. By using excellent audio-hardware the JACK daemon (Jack Audio Connection Kit) can reach latency < 1ms, similar to the MacOS X 'coreaudio' system." http://proaudio.tuxfamily.org/wiki/inde ... %29_Kernel

You don't want a system inferior to Mac or Windows, you want the best.

Some people on here say that "you don't need latencies that low, it's not a competition, whatever works ok on your system is good enough", but with so many computers in the world, what works on your pc may not on your neighbor's. More efficiency means that more people can use your OS, and lowers the risk of something unexpected happening when you are recording.

The reason other distro maintainers say they don't include an rt-kernel is because of the difficulties involved in compiling closed-source Nvidia drivers. (Although I suspect rt-kernels historically being harder to compile may be the real reason.) Studio 13.37 made the choice of giving priority to the user having the best kernel for audio production, as music production is its entire focus and raison d'etre.

Interesting. So as a teacher and someone advising others as well as being someone who wants to explore whatever gets me the best system, maybe I should still try RT after all in addition to the low-latency kernel just for comparison? I don't lose anything right? Because I can still just not use the RT kernel even if I go and install it…

And this seems interesting, if odd:

The USB interrupt period is 1 msec. To be able to get lower latency with jack when using it with an USB device, you have to use a setting as 48kHz and 3 period. It will makes the buffer time a multiple of 1 msec and you will get a much lower latency as with the default 2 period. Additionaly, loading the snd-usb-audio with the parameter "nrpacks=1" will give you a much lower latency (for this to work take care that CONFIG_USB_BANDWIDTH is not set and CONFIG_USB_DYNAMIC_MINORS is not set in your running kernel).

But I will note, this whole page you linked to is old and references the pre-v3 kernel. The newest kernel has two factors that I've heard: 1. people say that RT is not needed anymore like it used to be, and 2. RT is easier to install and readily available now. Obviously these are sort of opposing facts. But overall, I wonder if the comparison to Mac and all the other stuff from that is really just outdated…

Another thing to consider is: why does the rt-kernel team continue to put work into making patches, if there's no use doing it with newer kernels? I'll give you a hint: it's not for controlling laser beams.

Does anyone really think Ingo Molnar and the other developers just like wasting their time for no reason?

For reference, I tried simply turning off the wireless (unchecking "enable wireless" in the network settings) and that didn't help.

Try turning it off in the BIOS. If your problem is a piece of hardware asking for something to do every so often, then there may be a difference between OFF and Windows-Is-Not-Using-It.

With care, try turning off any other stuff you see there that you may not need.

Try to do it one thing at a time --- for the obvious reasons, and take careful notes of what you change for the even more obvious reasons!

There's another thing, which I can't just now remember the details of: if you have a multicore processor, make sure all the cores are handling hardware interups. If you need, I'll try to dig that out, but others here are much better informed than I am anyway.

"The main goal in audio-processing is the latency. The latency is the delay between signal-creating and reaching the processing in the system (e.g time between pressing a key on the keyboard and hearing the tone)

I don't think I agree. The main goal in audio processing is not to be interupted --- which is the goal of the real-time kernel. But it is a confusing word, and there is, I think, a definition of latency which is how long your process is guranteed the CPU's attention without being interupted. None of this is the same as the latency displayed by Jack, which is the latency you guys want to know about when recording, monitoring, etc: the one that makes it hard to sing when the sound in your headphones is noticably behind your voice.

There is something horrible called DPC latency. Google will explain. It is just nasty beyond words, and can make a PC unsuitable for even playing background music.

ps

my intellect says, "hey, you're assuming everyone here is male (and heterosexual at that, or is a lesbian woman I guess).

Mine said, Hey, there's a recipe for electrocution!

Thad E Ginathom wrote:

For reference, I tried simply turning off the wireless (unchecking "enable wireless" in the network settings) and that didn't help.

Try turning it off in the BIOS. If your problem is a piece of hardware asking for something to do every so often, then there may be a difference between OFF and Windows-Is-Not-Using-It.

For reference, my later post clarified the situation:
http://www.linuxmusicians.com/viewtopic ... =30#p25825

Unchecking wireless does seem to fully disengage it, I just had additional problems that needed to be addressed as well. So it was a combination of things. And anyway, since updating to KXStudio 12.04, things are even better and smoother. But anyway, regarding this one issue of wireless, just unchecking the box in network setting does deal with that element.

Oh right, sorry.

4 background
http://linuxmusicians.com/viewtopic.php?p=3264#p3264

l0wt3ch wrote:Another thing to consider is: why does the rt-kernel team continue to put work into making patches, if there's no use doing it with newer kernels? I'll give you a hint: it's not for controlling laser beams.

Does anyone really think Ingo Molnar and the other developers just like wasting their time for no reason?

I certainly don't think the RT team members are wasting their time for no reason.

However, AFAIK their target audience isn't really the pro audio crowd. I think they actually are doing it for controling laser beams, other machinery and stock exchanges.

l0wt3ch wrote:The reason other distro maintainers say they don't include an rt-kernel is because of the difficulties involved in compiling closed-source Nvidia drivers

The trouble is you cannot compile closed-source drivers, as you don't have the source, right?

So if you want to support closed drivers you'll have to keep any behaviour they rely on - because you can't change/fix it.