Nature of xruns
I never paid attention to mentions of xruns since I rarely got
them using a stock Fedora 8 kernel (and F6 before that) on a
x86_64 architecture, 4GB RAM. Yesterday though, I got plenty of
them and my observation is that in this case any real-time
feature associated to the kernel does not matter. In this case
the xruns are made by the way applications handles
stuff (whatever that is). So that makes me think that there
ought to be a guideline, a best practices in developing Linux
audio/jack applications.
Here's the observation setup.
First, the song. The song does not matter, It always plays
fine. The song is made by the use of Seq24 which drives several
soundfonts loaded by Qsynth in different engine instances, as
well as two sounds made by Zyn. Qsynth has several instances of
FluidR3_GM (120MB) and one SGM (250MB) loaded.
Second, the xruns. I take the outputs and drive them through
jackmix, add electric guitar line-in from a Vox amp, and have the
outputs of jackmix feed into Qarecord. Start recording. The
.wav result is polluted with xruns.
Third, same song w/o xruns. I terminate jackmix and Qarecord
and launch Ardour. I run all outputs into Ardour, and run the
electric guitar as well. Add some Freeverb and MultiEQ. Record.
No xruns at all in the resulting .wav file.
From this it is obvious that the application layer helps a lot
in promoting xruns. It is safe to assume that Qarecord is a
quick hack. But, there's seemingly a big difference in
application design regarding the handling of audio/jack stuff
between Qarecord and Ardour since one produces a festival of
xruns and the other none.
My question is, is there a guide/HOWTO around that addresses
the proper design of audio/jack applications or, is - in 2009 -
the only to know about that is by actually going through the source
code of successful Linux audio/jack applications ?
Cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Dec 28 16:15:01 2009
This archive was generated by hypermail 2.1.8 : Mon Dec 28 2009 - 16:15:01 EET