24 Dec
2009
24 Dec
'09
7:32 p.m.
To get jack2's sync mode through qjackctl, go to the Setup window, and
add "-S" (capital S) to the end of the "Server Path" text. It is
important to not have extra spaces in that text, the server won't start
if you do.
Your report is most interesting. I am very glad to hear of ChickenSys
Translator; if I ever need it, I'm buying it (I'll run it in a VM of
course *grin*). I do have to wonder about the crashing. If the
original SF2 was bad enough, it could crash fluidsynth quite easily, and
at least in theory, the ChickenSys Translator could have translated the
badness of the original SF2 over. "Badness" could be many things; I
have been lately studying a bit of what really can go into an SF2 (or a
gig), and there's all sorts of transforms, effects, etc. If the
original SF2 was made with the wrong overabundance of that stuff, the
process trying to play it (or the gig converted from it) would simply
tie itself into a CPU-load knot and die, perhaps by trying to create too
much simultaneity in reverb (for an oversimplified example). And if
anything Jackish fails in really the wrong way (CPU overload is often
one way), it often takes Jack with it. I would love to see an
"auto-restart" in qjackctl :-)
But jack2 certainly is far more able to handle horsepower problems. I
am so happy it's in Debian Experimental!!! I wonder if LinuxSampler is
prepared to handle multi-CPU the way jack2 is?
J.E.B.
Thanks Jonathan for the heads up on Jack2!
A quick update:
If you remember form my earlier posts (re: Fluidsynth, soundfonts, jack,
and latency), I'd devised a "stress test", with the following results:
(a) stable with a 1.6 GB piano sample in linuxsampler (b) promptly crash
with a 8.2Mb string soundfont with any fluidsynth-based application.
By crash, I mean jack requiring a restart, making things unusable for
live performance.
My strong suspicion was a bug with fluidsynth, to which I did receive
helpful replies.
Subsequently, I came across ChickenSys Translator, which can convert a
soundfont to a gigastudio sample. I converted the same 8.2 Mb string sf2
to a gig, and guess what - now with the same stress test, linuxsampler
crashes jack!
So the issue is not really with fluidsynth, but with jack itself. David
had rightly suspected something to this effect, and Josh had suggested
that Jack2 would be more resilient.
I now believe the improved performance in my stress test when I upgraded
jack was due to switching from jack to jack2. My system has subsequently
become much more stable. I now need to try out the --synch mode in jack2.
Quick question: How do I get into --synch mode using qjackctl?
Looking forward to inputs/suggestions.
Cheers,
Guru
[P.S. I hope I haven't hijacked the thread topic...]
Jonathan E. Brickman wrote:
I think I've got it :-) Muchas gracias to
Joakim Hernberg, who posted
the jack2 profiling document. I read it about five times, trying to
ponder what my first step might be given that info. It discusses two
major modes of jack2: the default, which is asynchronous, and another,
which is synchronous. Under asynch, my stress-test yields zero xruns
(or close) at 5.3 ms (as reported in Qjackctl); but under synch, my last
two tests say kosher at 0.667 ms *grin* Shocking. That synch makes a
whole lot of difference. I can just imagine jack2 jockeying all four
CPUs to make that happen :-) I'll be doing a lot more stress-testing to
prove it, but for right now, frames/period are 64, sample rate 192000,
two periods/buffer :-) :-) I praise the Lord, and I thank everyone for
the help!
J.E.B.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user