Linux Jack/Alsa Possible Realtime Issues?

Help, Support & Bugs
1

I looked through the stickies, didn’t see my issue directly addressed, so sorry if I’m beating a dead horse.

Running Renoise as I’ve done for a few years now, but I’m making the jump from ALSA to JACK.

So far, I’ve got it set up fine, running Realtime, playing through my USB interface. All is well, it sounds great, etc.

However, when either the CPU usage or RT usage percentage hits 100%, Renoise freezes, understandably. (I’m assuming it’s JACK’s RT % that’s causing this and not Renoise, as I disabled CPU overload handling.)

Is there a really good way to remedy this? I increased the client timeout as suggested by Renoise, but this doesn’t really seem like a “fix” to me.

I’m not OVERLY concerned about having amazing latency, as I don’t use MIDI input or anything; I work entirely with output, basically.

It would stand to logic, to me, that the solution is going to have to be trading latency for stability, just like in Windows, right?

I tweaked some settings in JACK:

Frames/Period (Buffer): 1024
Timeout (msec): 2000
left Output Latency on 0

I have Realtime and Force 16-bit enabled.

Now, after running one of the Renoise demo songs for a while, the CPU usage obviously goes up as more instruments/samples are being played. When it gets near/hits 100%, JACK displays this:

22:32:22.698 XRUN callback (1).
**** alsa_pcm: xrun of at least 1.523 msecs
**** alsa_pcm: xrun of at least 1.573 msecs
**** alsa_pcm: xrun of at least 1.548 msecs
**** alsa_pcm: xrun of at least 1.537 msecs
**** alsa_pcm: xrun of at least 1.704 msecs
**** alsa_pcm: xrun of at least 1.325 msecs
**** alsa_pcm: xrun of at least 1.574 msecs
**** alsa_pcm: xrun of at least 0.823 msecs
**** alsa_pcm: xrun of at least 0.720 msecs
**** alsa_pcm: xrun of at least 0.653 msecs
**** alsa_pcm: xrun of at least 0.427 msecs
**** alsa_pcm: xrun of at least 1.371 msecs
**** alsa_pcm: xrun of at least 1.405 msecs
**** alsa_pcm: xrun of at least 1.582 msecs
**** alsa_pcm: xrun of at least 1.509 msecs
**** alsa_pcm: xrun of at least 1.746 msecs
**** alsa_pcm: xrun of at least 1.481 msecs
**** alsa_pcm: xrun of at least 1.744 msecs
**** alsa_pcm: xrun of at least 1.802 msecs
**** alsa_pcm: xrun of at least 1.547 msecs
**** alsa_pcm: xrun of at least 1.165 msecs
**** alsa_pcm: xrun of at least 1.554 msecs

And repeats this cycle, more or less, until audio stops playing entirely, and then displays this:

22:32:42.344 XRUN callback (172).
delay of 776.000 usecs exceeds estimated spare time of 638.000; restart …
delay of 760.000 usecs exceeds estimated spare time of 638.000; restart …
delay of 790.000 usecs exceeds estimated spare time of 638.000; restart …

And that message is repeated ad nauseum until either Renoise or JACK crashes. (Appears to be Renoise crashing.)

Thoughts?

Oh, I should also note that even if I bypass JACK entirely and simply use ALSA output through Renoise, CPU usage still skyrockets and audio becomes incredibly choppy at the same point in the song that it does with JACK output.

Could this be an issue with using Realtime priority?

Also, Periods/Buffer is set to 3 as recommended. I’m on an IBM Thinkpad, however, I am using an external USB interface for audio. Would it be better set on 2?

2

Some slightly more information on the problem:

Song used for reference is DemoSong - BeatSlaughter vs. Tenda - PsyDrums

No matter what settings I’m using on either ALSA driver or JACK, at pattern 6, labeled “Break starts,” audio becomes choppy and Renoise eventually crashes.

I’ve now tried with Realtime Priority both enabled and disabled in JACK. Virtually the same results.

CPU usage in Renoise is only about 50-60% with all instruments and effects playing, with RT turned OFF. I don’t think CPU overload is the issue. (My Thinkpad is an X41, which has a Pentium M-Centrino 1.6ghz CPU, 1.5GB RAM, and I’m using a solid-state hard drive. 32-bit linux.)

I’m kinda stumped. The part that confuses me is that it plays beautifully right up until it hits pattern 6; the delay/echo effect on the newly-introduced instrument at that point seems to be what’s devastating everything.

My USB sound card is a Behringer UCA-200, and like I said, built-in sound is an Intel chip, but I’m not using that anyway.

3
  • Are you running a realtime (rt) kernel? Which version?
  • Which Linux distribution are you running?
  • Have you setup /etc/security/limits.conf to allow for realtime thread creation? (Linux FAQ - Renoise User Manual)
4

1.) Don’t believe I’m on a realtime kernel

2.) Ubuntu 9.10 32-bit

3.) yes, my limits.conf file has been edited

*edit - I take that back, I had my limits.conf edited with the following:

@josh - rtprio 99
@josh - memlock unlimited

And I added the “nice” line to make it all:

@josh - rtprio 99
@josh - memlock unlimited
@josh - nice −10

I know I read somewhere that the “memlock” line was required… Hmm.

5

To install a realtime kernel on ubuntu you can simply do a
“sudo apt-get install linux-rt”

In limits.conf, remove the @, so use:
josh - rtprio 99
josh - memlock unlimited
josh - nice −10"

or add josh to a group audio and use:
@audio - rtprio 99
@audio - memlock unlimited
@audio - nice −10"

And yes, Renoise needs a high jack timeout setting, else Jack tends to disconnect from Renoise quite easily. The higher timeout does not hurt nor break something…

6

Thanks for the reply, Taktik. Doing the things you mentioned as we speak. 183 megs for the RT Kernel install, yeesh!

So if I understand this correctly, the Realtime priority option in JACK actually doesn’t work properly UNLESS you have a Realtime kernel?

7

No luck, Tiktak.

Installed the RT kernel, changed the limits.conf to be properly formatted, and still the same issue.

Here’s a screenshot of my current settings:

http://img64.imageshack.us/img64/1227/11448096.jpg

Still getting occasional stutters and complete Renoise crash about a minute into the song.

8

It honestly seems like more of a Renoise error at this point. Audio plays fine using JACK until a bunch of instruments/samples start playing and the CPU % meter in Renoise jumps to 70%, which is when it starts getting choppy. After that, it generally crashes and says CPU was being utilized too much.

Maybe my issue is more CPU-related? Why would this be?

9

What do you mean with “crashes”? That it shuts down or that it stops playing. 70% of CPU usage is a lot, thats actually sems to be the root of the problem.
Are you probably simply using more DSPs and instruments than your computer can handle? Does the same song perform better when using ALSA in Renoise then with Jack?

A realtime kernel or security limit options will not use less CPU. They only help that you get less crackles at high CPU usages. Such things can not make your computer faster, they can only make it respond better at high CPU loads.

10

By “crashes” I mean audio stops playing and Renoise displays an error dialog literally saying, “Used too much CPU for too long, so we stopped audio.”

Audio plays much better in JACK than ALSA.

And the song in question is one of the Demo songs, so I guess it would strike me as a bit odd if even it didn’t play properly.

Again, my specs are Pentium M-Centrino 1.6ghz, 1.5GB RAM, 60GB solid-state hard drive, so I really can’t imagine it’s a performance issue. My laptop might not be brand new, but it should easily be enough to handle Renoise, shouldn’t it?

11

No, sorry. The demo songs are not meant to be playable on every computer. They use tons of DSP and stuff. They do need a decent up to date setup. Our bad that we have not made that clear, that you think something’s wrong.

Computers can not be fast enough for real-time audio. Whatever limit we set for the demo songs, there will always be computers that can not handle them, while we also want to show Renoises possibilities to all “up to date” setups.

There is not such thing like a setup thats fast enough for Renoise. This just depends on what you throw at Renoise. Its an open system, you have the choice of how many tracks, DSP and instruments you use.

If you are interested in a set of low (lower) CPU XRNS songs, then please have a look at the Renoise Indamixx competition songs: http://www.renoise.com/community/competitions/indamixx/

12

Dunno if it helps, here’s my configuration that works nicely WITHOUT a RT kernel, just the generic one, on Ubuntu 9.10 64Bit with Renoise 2.5.0 RC1. I have no problems playing the PsyDrums demo song. CPU is AMD Athlon 64 X2 3800+ Dual Core.

/etc/securoty/limits.conf
(with my user added to the audio group):
@audio - rtprio 99
@audio - memlock 1000000
@audio - nice -10

Jack command line:
/usr/bin/jackd -R -P89 -p128 -t5000 -dalsa -dhw:0 -r44100 -p256 -n4 -S

Latency reported in qjackctl setup screen: 23.2 msec

HTH, tell me if you’d like more info.

EDIT: didn’t see the last posts, so might not be helpful after all… so well.

13

Hey Taktik,

Thanks for the heads up; guess I didn’t realize Renoise could be a CPU-intensive program.

I’ll scope out some of the other demo songs mentioned and see how it goes.

If that is the issue, the good news is my JACK settings have been working relatively well all along, ha!

14

I am enthralled right now!

After some advice from a friend, and taking into account that my system may be SLIGHTLY an underperformer for the Renoise demo songs, he suggested a few tweaks, among them using the CPU Frequency Scaling widget and switching it onto Performance.

This solved my problem in one fell swoop. I can play every demo song on the list now, with the highest peak at 65% or so during the Hunz song “Soon Soon.”

I’m playing through JACK at a buffer of 128, which I can live with, though I bet I can get it lower now that CPU issue is under control.

I’d love any other general system-wide performance tweaks that may help even more! And for you Ubuntu/Gnome users out there, try adding the CPU Frequency Scaling widget and switching it to Performance!

15

Heck, that’s a great tip! I already wondered where and how gnome has hidden this. Switching to “Performance”, avoiding that the CPU gets throttled, makes a BIG difference for Audio apps.

Thanks for the tip.

Here is a small HowTo for Ubuntu/gnome: Howto Change CPU Frequency Scaling in Ubuntu – Ubuntu Geek