Re: [Jack-Devel] Installers for Jack 1.9.8 (SVN 4356) for Windows 64 and 32 bits

Hi Devin,

http://dino.drealm.info/peter/jacklogs.7z contains:
jack-128-latency.log	- latency test for jackd run with -p 128
jackd-128.log		- jackd log for above
jack-latency.log	- latency test for jackd run without -p 128
jackd.log		- jackd log for above

Hope that's some help!

Cheers,

-- Peter

On 29/04/2011 19:08, Devin Anderson wrote:
> On Fri, Apr 29, 2011 at 2:09 AM, Peter L Jones <[hidden]> wrote:
> 
>> I tried using the alias names (e.g. "winmme:AudioFire4 MIDI:in2") and QJackCtl
>> showed the latency tester connecting to the ports.  However, it refused to run
>> the test, just sitting at "Waiting for connections ..." until I hit Ctrl-C.
>> Any ideas on that?
> 
> Not really.  I don't have a Windows machine. :(  I assume that a
> semaphore isn't signaling correctly.
> 
>> Anyway, here are the latest results.  It's a bit of a mixed bag compared with
>> the earlier test (4340 version).  Average latency is down, average jitter is
>> up.  My AudioFire4 is the only device on my Firewire bus and it's using the
>> latest Windows 7 Echo Audio driver.
> 
> Can you run JACK in verbose mode and send me the output of JACK?  I've
> inserted debugging code around the MIDI output timer calls so that I
> can figure out if the timer is the source of the jitter on Windows.
> 
> What I find most interesting is that this result:
> 
>> Reported out-port latency: 11.61-12.63 ms (512-557 frames)
>> Reported in-port latency: 11.61-12.63 ms (512-557 frames)
>> Average latency: 45.98 ms (2028.04 frames)
>> Lowest latency: 32.13 ms (1417 frames)
>> Highest latency: 61.53 ms (2714 frames)
>> Peak MIDI jitter: 29.41 ms (1297 frames)
>> Average MIDI jitter: 6.10 ms (268.63 frames)
> 
> ... and this result:
> 
>>> Reported out-port latency: 2.67-3.67 ms (128-176 frames)
>>> Reported in-port latency: 2.67-3.67 ms (128-176 frames)
>>> Average latency: 43.34 ms (2080.89 frames)
>>> Lowest latency: 30.98 ms (1528 frames)
>>> Highest latency: 68.25 ms (3195 frames)
>>> Peak MIDI jitter: 37.27 ms (1667 frames)
>>> Average MIDI jitter: 3.81 ms (166.13 frames)
> 
> ... have similar latency and jitter values, but have completely
> different reported in-port and out-port latency values, meaning that
> you ran JACK with two different period-size/period-count/sample-rate
> combinations, and yet the MIDI latency was still about the same, which
> means there's something that's not changing with regards to latency.
> I can think of a few possibilities:
> 
> 1.) The timer code could be erroneous.  If I can see the JACK output
> in verbose mode, then I can take steps in figuring out if this is the
> problem.
> 
> 2.) The timer resolution could be off.  The code attempts to set the
> timer resolution to the lowest possible available resolution, but
> Windows is not very good at doing things in realtime.  One possible
> solution to this problem would be to explicitly set the process
> priority.  I've talked a bit with Stéphane about this.  Seeing the
> output of JACK in verbose mode will help me figure out if this is the
> problem.
> 
> If this is the problem, then I can investigate the usage of other
> Windows timing mechanisms.  Windows has a lot of different timers, but
> it's not always clear which timers work well and which ones don't.
> Right now, the code uses a "waitable timer", but it could use a queue
> timer.  The multimedia timers are marked as obsolete for whatever
> reason, though a lot of multimedia code still appears to use them.
> 
> 3.) The offset I'm computing for received MIDI events could be off.
> The WinMME library has this weird convention whereby it resets a
> millisecond counter to 0 somewhere inside 'midiInStart', and all
> received MIDI events then have a timestamp computed, which is
> basically a millisecond offset to the time that the millisecond
> counter was reset.  Unfortunately, there's no way to figure out what
> the absolute time was when the counter was reset in 'midiInStart',
> what the counter is at any time, and how much time passes between the
> time that the driver "timestamps" the MIDI event, and the time that
> the MIDI in callback is called with the message itself.  It's *very*
> frustrating.
> 
> I've seen a few different schemes that attempt to solve this problem.
> The scheme I'm using increases latency a bit, but *should* cause 0
> jitter, which I think is more important than a bit of latency.
> 
> 4.) The timing of the WinMME driver could be off.  This is the
> worst-case scenario, as there's absolutely nothing that can be done
> about this.
> 
> Anyway, if you (or anyone reading this) could send me the verbose
> output, then I can get started on figuring out the problem.
> 
> Thank you for all of your help thus far.  I appreciate it a lot. :)
> 

1304191786.32005_0.ltw:2,a <iphnu0$l7b$1 at dough dot gmane dot org>