[LAU] rtirq - what does it improve, and how can I measure it?
ailomaa at warpmail.net
Mon May 7 13:16:37 UTC 2012
On 05/07/2012 02:32 PM, Ralf Mardorf wrote:
> On Mon, 2012-05-07 at 14:06 +0200, Kaj Ailomaa wrote:
>> ..and are there other ways to measure improvement for audio operation
>> other than spotting xruns at different latency settings, and reading the
>> rtprio for various devices using the 'ps' command?
> For MIDI there e.g. is JACK2's jack_midi_latency_test especially
> interesting when using -Xalsarawmidi.
> Most important, for audio and MIDI there's your trained hearing.
This is something I always put first when making music, using any
equipment, or any method to make it.
> If you e.g. are working for an audio studio and your engineering does
> sound as it should sound and you've got similar equipment at home, but
> it doesn't sound as it should sound, than you'll like tools for
> troubleshooting. Assumed Jack1 does disconnect clients, than you'll have
> tools for troubleshooting. Assumed your MIDI sequencer has an audible
> bad timing, or simply it won't groove, than you'll use tools for
> troubleshooting. Assumed a digital copy internal Linux has an audible
> quality loss, than you might compare spectrograms using Audacity.
> Assumed ... [snip]
> If everything sounds good for you, no app will crash etc., than it's
> irrelevant what the output of rtirq status and other control methods is.
> If you know that your machine has weak points, than you'll get stuff
> like rtirq already working, before you try to fix other issues or yu
> even d a test recording.
> rtirq - what does it improve, and how can I measure it?
> It improves the priority. What would you like to measure? Perhaps you
> like to monitor using top, atop, htop?
I'm merely being interested in finding out more about what problems
exist tuning your machine for "pro" audio, since I'd like to participate
in making this easier for linux users in general.
Right now, I've been looking at this particular area, and I'm trying to
find out what the problems are, which problems are solved, and if there
are any problems that are not solved.
> Why will you measure or monitor? If everything is ok, than it's ok, than
> it's ok. If not, you'll find out what's going wrong. IMO the first thing
> to do, is to run top, to e.g. ensure that there isn't an instance of
> Firefox using 70% RAM and 85% CPU resources.
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
More information about the Linux-audio-user