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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
