7 May
2012
7 May
'12
3:16 p.m.
On 05/07/2012 02:32 PM, Ralf Mardorf wrote:
On Mon, 2012-05-07 at 14:06 +0200, Kaj Ailomaa wrote:
This is something I always put first when making music, using any
equipment, or any method to make it.
..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?
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.
Regards,
Ralf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user