Re: [LAU] rtirq - what does it improve, and how can I measure it?

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.

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?

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.

Regards,
Ralf

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon May 7 16:15:04 2012