Re: [Qmidiarp-user] Re : Re : Re : Feature Request: Export Functionality

[S C R. <rig...@gm...>]

On Tue, Jun 14, 2011 at 1:38 PM, Frank Kober <goe...@ya...> wrote:
> Thanks Steve,
> the examples clearly show the problem, however more questions before digging into what this could be (I clearly don't reproduce it here on an old 2.6.33 rt kernel):
> 1) Does the jitter appear as well when not using jack transport sync? No proof needed if your impression is so.
> 2) What is your JACK latency ?
> 3) Do you use a CPU frequency governor like ondemand that might vary CPU frequency during play?
>
> Reasons for my questions are, I'd like to know whether qmidiarp just poorly syncs due to some reason or whether the ALSA timer for some reason is unstable
>
> Thanks in advance
> Frank
>

I experimented with it a bit more and I can't for sure say if there is
a difference between using jack transport sync and the internal timer.
 It sounds like it's in time without jack transport sync, but to
compare, I tried using jack transport sync with no accompaniment and
it sounded fine there as well.  So it seems that it's just when there
are other parts playing that it sounds like it's not in time.

But anyways, to answer your other questions: I went back to a rt patch
2.6.33 kernel to record the examples.  Just FYI, my laptop isn't
completely supported until 2.6.35 and one of the workarounds I need to
keep it from locking up on older kernels is to boot with "nohpet".
The behavior is the same, though,  between 2.6.39 and 2.6.33-rt.

According to Qjackctl, the latency is 2.9ms (64 frames/period, 2
periods/buffer).  The CPU frequency governor is configured for
"performance".

--Steve