Search:
Submit Search


DIY MIDI encoder: survey about hardware/software features

Building organ consoles for use with Hauptwerk, adding MIDI to existing consoles, obtaining parts, ...

Re: DIY MIDI encoder: survey about hardware/software feature

Postby elia » Tue Jul 22, 2014 5:19 am

The oscilloscope trace of Nick is the most important information up to now. The correct information is closer to the analog domain. However since the processing must be done in the digital domain with a 1-bit AD converter must also consider the second element of uncertainty: the AD conversion system and and its electronic. (Also should be also added the physical connections of the wires of different lengths welded/pressed and shielded/unshielded.)

Without weighing the matter say that the 1-bit AD conversion presents an indeterminate intermediate zone 0 ... 5V where the conversion value is chaotic. Some electronic boards have a hysteresis circuit that mask this phenomenon, which is generally not useful to the software unless you want to push us in sophisticated processing .
The software can only accept what the electronic board needs to do. However, several electronic boards do different jobs and it is not the same thing for the software.
With 2 contacts keyboards (M-Audio keysation 61es) you can for example use 2 different Digital I/O cards connected to 2 different diode matrix row to real-time compare which of the two conversion systems is the "best" for the work to be done: greater stability?, lower latency?, less noise?, less processing load on the CPU? ..., embedded system on microcontroller?...

Enumerate all the possible cases makes little sense because things can change based on many variables: the wear, temperature, humidity, organist, ...

The only sensible software solution must be based on an adaptive approach that is able to learn and remember the story to fit the present and the future and also highlights cases out maximum tolerance (it is hard to think of an improvement over time).
Only software can lose all this time in an X-ray of the dynamics of the health system, especially if you want to go in the temporal chaotic domain of bounce.

In order to do this you have to do the sampling time at least 1/10 or 1/20 of the minimum bounce time. Nick observes 50uS in the analog domain. In the digital domain with hysteresis, the time is shortened to less than 25uS so it might be enough 1uS (1 MHz sample rate) sampling time.

At these levels of parallel sampling you can only use PCI, PCIe and Thunderbolt. USB and Ethernet are not suitable for processing but only for the data transport (the latency may exceed 100us). Obviously if you multiplex events in the same packet you can improve performance but you also introduce a jitter which should be corrected with a timestamp ... and it becomes too complicated and impractical ...

I can only give you real data as did Nick and John... but as I said I need a bit 'of time ... unless you want to create a collaborative software development on github.com, at least the basic functionality on Linux platform as if you were to do the work that Nick did with the Atmel microcontroller...but it is likely that there are more people interested in the results that the implementation hardware/software work.
Last edited by elia on Thu Jul 24, 2014 4:54 am, edited 1 time in total.
Elia
User avatar
elia
Member
 
Posts: 124
Joined: Mon Oct 27, 2008 2:11 pm
Location: Italy , Padova

Re: DIY MIDI encoder: survey about hardware/software feature

Postby NickNelson » Wed Jul 23, 2014 10:16 am

I'm sorry to say that in my previous post I misreported the transition times (and have edited the post accordingly). The transition times for 'normal' playing may be up to 1mS. But, this is still considerably better than other common types of mechanical switches or contacts used in organ manuals. In the past I have tested a variety including reed switches, microswitches, simple push switches etc, and in general I find that a bounce time of 4 mS minimum needs to be taken into consideration. I even constructed a special contact arrangement that was as unsatisfactory as I could imagine (to test my debouncing code) that reguarly bounced in excess of 25mS.

Its worth reiterating that, so far as I can tell, the conductive rubber membrane contacts don't bounce at all, but rather exhibit a 'ramping' of the output voltage, the slope of which is mostly determined by the rate at which the key is pressed or released. By also taking account of the fact that the Atmel microcontrollers (and I presume others like the PICs) have about 0.4V hysteresis on their inputs I conclude that false retriggering of notes won't be a problem with this type of contact even if no debouncing were applied. However, the point at which the transition is detected will vary somewhat with the rate of key movement (a slow press detection could possibly be delayed by 500uS compared to a fast press.

Nick
User avatar
NickNelson
Member
 
Posts: 778
Joined: Tue Dec 20, 2005 11:31 am
Location: Leeds, UK

Re: DIY MIDI encoder: survey about hardware/software feature

Postby elia » Thu Jul 24, 2014 2:17 pm

Considered the Nick final details, the ability to not use hysteresis to predict in advance the status change, then I can widen the scope of the discussion to the question asked by Steve Till: an encoder MIDI interface with gigabit ethernet transport layer.
Nick showed graphically the performance of a M-Audio switch key (say an order of magnitude of 10us, in the best case). This means that the transport interface should be comparable to these values ​​and at the same time should not be a source of indeterminate latency and jitter. It is not enough to say gigabit ethernet. The latency and jitter does not depend directly on the bandwidth. 1Gbps Ethernet and PCI bus 133MB/s have the same bandwidth but the latency is dramatically lower with a deterministic character in the second case!
But determinism may also depend on the CPU hardware energy savings (Windows, for example) as you can see below in detail.

Pragmatic Network Latency Engineering, Fundamental Facts and Analysis
Rony Kay, Ph.D. President/CTO cPacket Networks
http://cpacket.com/wp-content/files_mf/introductiontonetworklatencyengineering.pdf

Unlike bandwidth, latency and jitter depend on the specific context of network topology and traffic conditions. If you cannot measure network latency, you cannot control it and cannot improve it. Keep in mind that dependencies of bandwidth and latency are context specific; improving the bandwidth may or may not be sufficient to improve latency. In practice, improving latency is harder than improving bandwidth. Linear scaling of bandwidth can be simply achieved by bundling several identical links in parallel, but it will not improve the network latency per packet. In real networks, there are multiple latency sources that impact the
performance of distributed applications like algorithmic trading. While the speed of light is a fundamental limit for moving bits from one location to another, additional practical factors include interface delays, processing delays, and queuing delays. The impact of various latency sources on distributed applications performance can vary widely across different environments. A key observation is that misinterpretation of the relative contribution of host latency and network latency to application performance can lead to expensive and unproductive optimization efforts.



In short, often the performance of Gigabit Ethernet are neither good nor deterministic (such as latency/jitter). Especially if you use the interfaces built into the motherboard and power saving CPU features and for this reason the alsa-midi-latency-test utility I have indicated ( https://github.com/raboof/alsa-midi-latency-test/ ) it is essential to analyze the particular case and if necessary to seek to apply optimizations.
10Gbps Ethernet and special Ethernet 100/1000Mbps cards (optimized for deterministic latency/jitter) can do an excellent job. In any case, you can do well with the more traditional products but not toys:
Intel ® Gigabit CT Desktop PCIe Adapter (also work on OSX with the official driver Intel82574L.kext)
http://www.intel.com/content/dam/doc/product-brief/gigabit-ct-desktop-adapter-brief.pdf
.


The following are the loopback latency measures (round trip) with ipMIDI packets (=MIDI over UDP multicast) between linux (http://qmidinet.sourceforge.net) and windows7 (http://www.nerds.de/en/%20ipmidi.html). Interestingly, the performance change significantly if you disable the power saving CPU features in Windows UEFI/BIOS motherboard.



continuous ipMIDI packets train (default : windows CPU energy saving enabled)

root@debian:/home/studio/alsa-midi-latency-test/src# time ./alsa-midi-latency-test -o 128:0 -i 128:1 -R -3 -w 0 -x -S 100000
> set_realtime_priority(SCHED_FIFO, 99).. done.
> clock resolution: 0.000000001 s

> sampling 100000 midi latency values - please wait ...
> done.

> latency distribution:
...
0.092000 -0.093000 ms: 1 #
...
0.099000 -0.100000 ms: 4 #
0.100000 -0.101000 ms: 25 #
...
0.102000 -0.103000 ms: 14 #
0.103000 -0.104000 ms: 74 #
0.104000 -0.105000 ms: 9 #
0.105000 -0.106000 ms: 12 #
0.106000 -0.107000 ms: 3 #
0.107000 -0.108000 ms: 17 #
0.108000 -0.109000 ms: 51 #
0.109000 -0.110000 ms: 37 #
0.110000 -0.111000 ms: 46 #
0.111000 -0.112000 ms: 131 #
0.112000 -0.113000 ms: 106 #
0.113000 -0.114000 ms: 83 #
0.114000 -0.115000 ms: 152 #
0.115000 -0.116000 ms: 159 #
0.116000 -0.117000 ms: 182 #
0.117000 -0.118000 ms: 395 #
0.118000 -0.119000 ms: 309 #
0.119000 -0.120000 ms: 155 #
0.120000 -0.121000 ms: 109 #
0.121000 -0.122000 ms: 90 #
0.122000 -0.123000 ms: 73 #
0.123000 -0.124000 ms: 57 #
0.124000 -0.125000 ms: 62 #
0.125000 -0.126000 ms: 70 #
0.126000 -0.127000 ms: 71 #
0.127000 -0.128000 ms: 265 #
0.128000 -0.129000 ms: 2511 #####
0.129000 -0.130000 ms: 3596 #######
0.130000 -0.131000 ms: 8526 ##################
0.131000 -0.132000 ms: 9918 ####################
0.132000 -0.133000 ms: 15280 ################################
0.133000 -0.134000 ms: 24219 ##################################################
0.134000 -0.135000 ms: 7052 ###############
0.135000 -0.136000 ms: 10798 ######################
0.136000 -0.137000 ms: 4948 ##########
0.137000 -0.138000 ms: 1528 ###
0.138000 -0.139000 ms: 1014 ##
0.139000 -0.140000 ms: 691 #
0.140000 -0.141000 ms: 1332 ###
0.141000 -0.142000 ms: 914 ##
0.142000 -0.143000 ms: 329 #
0.143000 -0.144000 ms: 148 #
0.144000 -0.145000 ms: 95 #
0.145000 -0.146000 ms: 61 #
0.146000 -0.147000 ms: 44 #
0.147000 -0.148000 ms: 24 #
0.148000 -0.149000 ms: 15 #
0.149000 -0.150000 ms: 12 #
0.150000 -0.151000 ms: 18 #
0.151000 -0.152000 ms: 10 #
0.152000 -0.153000 ms: 3 #
0.153000 -0.154000 ms: 6 #
0.154000 -0.155000 ms: 11 #
0.155000 -0.156000 ms: 4 #
0.156000 -0.157000 ms: 4 #
0.157000 -0.158000 ms: 2 #
0.158000 -0.159000 ms: 4 #
0.159000 -0.160000 ms: 7 #
0.160000 -0.161000 ms: 4 #
0.161000 -0.162000 ms: 5 #
0.162000 -0.163000 ms: 2 #
0.163000 -0.164000 ms: 2 #
0.164000 -0.165000 ms: 2 #
0.165000 -0.166000 ms: 4 #
0.166000 -0.167000 ms: 1 #
0.167000 -0.168000 ms: 4 #
0.168000 -0.169000 ms: 5 #
0.169000 -0.170000 ms: 12 #
0.170000 -0.171000 ms: 9 #
0.171000 -0.172000 ms: 8 #
0.172000 -0.173000 ms: 4 #
0.173000 -0.174000 ms: 8 #
0.174000 -0.175000 ms: 4 #
0.175000 -0.176000 ms: 4 #
0.176000 -0.177000 ms: 3 #
0.177000 -0.178000 ms: 3 #
0.178000 -0.179000 ms: 6 #
0.179000 -0.180000 ms: 34 #
0.180000 -0.181000 ms: 40 #
0.181000 -0.182000 ms: 68 #
0.182000 -0.183000 ms: 508 #
0.183000 -0.184000 ms: 356 #
0.184000 -0.185000 ms: 315 #
0.185000 -0.186000 ms: 1300 ###
0.186000 -0.187000 ms: 659 #
0.187000 -0.188000 ms: 294 #
0.188000 -0.189000 ms: 109 #
0.189000 -0.190000 ms: 38 #
0.190000 -0.191000 ms: 32 #
0.191000 -0.192000 ms: 41 #
0.192000 -0.193000 ms: 50 #
0.193000 -0.194000 ms: 56 #
0.194000 -0.195000 ms: 20 #
0.195000 -0.196000 ms: 7 #
0.196000 -0.197000 ms: 11 #
0.197000 -0.198000 ms: 5 #
0.198000 -0.199000 ms: 5 #
0.199000 -0.200000 ms: 2 #
0.200000 -0.201000 ms: 1 #
0.201000 -0.202000 ms: 5 #
0.202000 -0.203000 ms: 1 #
0.203000 -0.204000 ms: 8 #
0.204000 -0.205000 ms: 9 #
0.205000 -0.206000 ms: 10 #
0.206000 -0.207000 ms: 1 #
0.207000 -0.208000 ms: 2 #
...
0.209000 -0.210000 ms: 2 #
0.210000 -0.211000 ms: 2 #
...
0.213000 -0.214000 ms: 2 #
...
0.215000 -0.216000 ms: 1 #
...
...
... omitted results, insignificant
...
...
0.662000 -0.663000 ms: 1 #
...
0.678000 -0.679000 ms: 1 #


> SUCCESS

best latency was 0.092022 ms
worst latency was 0.677827 ms, which is great.

real 0m13.509s
user 0m0.192s
sys 0m0.328s



continuous ipMIDI packets train (optimized : windows CPU energy saving disabled)
root@debian:/home/studio/alsa-midi-latency-test/src# time ./alsa-midi-latency-test -o 128:0 -i 128:1 -R -3 -w 0 -x -S 100000

> set_realtime_priority(SCHED_FIFO, 99).. done.
> clock resolution: 0.000000001 s

> sampling 100000 midi latency values - please wait ...
> done.

> latency distribution:
...
0.069000 -0.070000 ms: 1 #
0.070000 -0.071000 ms: 1 #
...
0.077000 -0.078000 ms: 1 #
...
0.096000 -0.097000 ms: 1 #
0.097000 -0.098000 ms: 299 #
0.098000 -0.099000 ms: 2700 ###
0.099000 -0.100000 ms: 15898 #################
0.100000 -0.101000 ms: 5284 #####
0.101000 -0.102000 ms: 11493 ############
0.102000 -0.103000 ms: 48129 ##################################################
0.103000 -0.104000 ms: 9166 ##########
0.104000 -0.105000 ms: 1252 #
0.105000 -0.106000 ms: 582 #
0.106000 -0.107000 ms: 741 #
0.107000 -0.108000 ms: 486 #
0.108000 -0.109000 ms: 269 #
0.109000 -0.110000 ms: 289 #
0.110000 -0.111000 ms: 169 #
0.111000 -0.112000 ms: 242 #
0.112000 -0.113000 ms: 391 #
0.113000 -0.114000 ms: 243 #
0.114000 -0.115000 ms: 52 #
0.115000 -0.116000 ms: 33 #
0.116000 -0.117000 ms: 36 #
0.117000 -0.118000 ms: 91 #
0.118000 -0.119000 ms: 82 #
0.119000 -0.120000 ms: 81 #
0.120000 -0.121000 ms: 139 #
0.121000 -0.122000 ms: 185 #
0.122000 -0.123000 ms: 24 #
0.123000 -0.124000 ms: 20 #
0.124000 -0.125000 ms: 25 #
0.125000 -0.126000 ms: 20 #
0.126000 -0.127000 ms: 61 #
0.127000 -0.128000 ms: 61 #
0.128000 -0.129000 ms: 65 #
0.129000 -0.130000 ms: 64 #
0.130000 -0.131000 ms: 82 #
0.131000 -0.132000 ms: 23 #
0.132000 -0.133000 ms: 9 #
0.133000 -0.134000 ms: 6 #
0.134000 -0.135000 ms: 5 #
0.135000 -0.136000 ms: 1 #
0.136000 -0.137000 ms: 5 #
0.137000 -0.138000 ms: 1 #
0.138000 -0.139000 ms: 3 #
0.139000 -0.140000 ms: 3 #
0.140000 -0.141000 ms: 2 #
...
0.142000 -0.143000 ms: 1 #
0.143000 -0.144000 ms: 3 #
0.144000 -0.145000 ms: 1 #
...
0.147000 -0.148000 ms: 7 #
0.148000 -0.149000 ms: 10 #
0.149000 -0.150000 ms: 4 #
0.150000 -0.151000 ms: 30 #
0.151000 -0.152000 ms: 49 #
0.152000 -0.153000 ms: 16 #
0.153000 -0.154000 ms: 54 #
0.154000 -0.155000 ms: 68 #
0.155000 -0.156000 ms: 55 #
0.156000 -0.157000 ms: 16 #
0.157000 -0.158000 ms: 103 #
0.158000 -0.159000 ms: 95 #
0.159000 -0.160000 ms: 15 #
0.160000 -0.161000 ms: 8 #
0.161000 -0.162000 ms: 6 #
0.162000 -0.163000 ms: 4 #
0.163000 -0.164000 ms: 12 #
0.164000 -0.165000 ms: 25 #
0.165000 -0.166000 ms: 3 #
0.166000 -0.167000 ms: 2 #
0.167000 -0.168000 ms: 2 #
0.168000 -0.169000 ms: 1 #
0.169000 -0.170000 ms: 16 #
0.170000 -0.171000 ms: 4 #
0.171000 -0.172000 ms: 10 #
0.172000 -0.173000 ms: 36 #
0.173000 -0.174000 ms: 31 #
0.174000 -0.175000 ms: 38 #
0.175000 -0.176000 ms: 21 #
0.176000 -0.177000 ms: 79 #
0.177000 -0.178000 ms: 15 #
0.178000 -0.179000 ms: 28 #
0.179000 -0.180000 ms: 21 #
0.180000 -0.181000 ms: 18 #
0.181000 -0.182000 ms: 53 #
0.182000 -0.183000 ms: 63 #
0.183000 -0.184000 ms: 27 #
0.184000 -0.185000 ms: 43 #
0.185000 -0.186000 ms: 47 #
0.186000 -0.187000 ms: 16 #
0.187000 -0.188000 ms: 4 #
0.188000 -0.189000 ms: 2 #
0.189000 -0.190000 ms: 1 #
0.190000 -0.191000 ms: 3 #
0.191000 -0.192000 ms: 2 #
0.192000 -0.193000 ms: 3 #
...
0.194000 -0.195000 ms: 2 #
...
0.196000 -0.197000 ms: 1 #
...
0.202000 -0.203000 ms: 1 #
...
...
... omitted results, insignificant
...
...
0.602000 -0.603000 ms: 1 #
...
0.604000 -0.605000 ms: 1 #


> SUCCESS

best latency was 0.069153 ms
worst latency was 0.604032 ms, which is great.


real 0m10.285s
user 0m0.112s
sys 0m0.408s



random time interval (from 6ms to 12ms) continuous ipMIDI packets train (default : windows CPU energy saving enabled)
root@debian:/home/studio/alsa-midi-latency-test/src# time ./alsa-midi-latency-test -o 128:0 -i 128:1 -R -3 -w 6 -r -S 1000

> set_realtime_priority(SCHED_FIFO, 99).. done.
> clock resolution: 0.000000001 s
> interval between measurements: 6.000 .. 12.000 ms

> sampling 1000 midi latency values - please wait ...
> done.

> latency distribution:
...
0.154000 -0.155000 ms: 1 #
...
0.188000 -0.189000 ms: 1 #
...
0.195000 -0.196000 ms: 3 ###
...
0.198000 -0.199000 ms: 2 ##
0.199000 -0.200000 ms: 1 #
...
0.201000 -0.202000 ms: 1 #
0.202000 -0.203000 ms: 1 #
...
0.204000 -0.205000 ms: 1 #
...
0.206000 -0.207000 ms: 1 #
0.207000 -0.208000 ms: 1 #
0.208000 -0.209000 ms: 2 ##
0.209000 -0.210000 ms: 1 #
0.210000 -0.211000 ms: 2 ##
0.211000 -0.212000 ms: 2 ##
0.212000 -0.213000 ms: 3 ###
0.213000 -0.214000 ms: 4 ####
0.214000 -0.215000 ms: 6 ######
0.215000 -0.216000 ms: 4 ####
0.216000 -0.217000 ms: 7 #######
0.217000 -0.218000 ms: 4 ####
0.218000 -0.219000 ms: 5 #####
0.219000 -0.220000 ms: 3 ###
0.220000 -0.221000 ms: 2 ##
0.221000 -0.222000 ms: 6 ######
0.222000 -0.223000 ms: 2 ##
0.223000 -0.224000 ms: 4 ####
0.224000 -0.225000 ms: 5 #####
0.225000 -0.226000 ms: 2 ##
0.226000 -0.227000 ms: 7 #######
0.227000 -0.228000 ms: 2 ##
0.228000 -0.229000 ms: 3 ###
0.229000 -0.230000 ms: 5 #####
0.230000 -0.231000 ms: 2 ##
0.231000 -0.232000 ms: 3 ###
...
0.233000 -0.234000 ms: 1 #
0.234000 -0.235000 ms: 1 #
0.235000 -0.236000 ms: 3 ###
0.236000 -0.237000 ms: 2 ##
0.237000 -0.238000 ms: 6 ######
0.238000 -0.239000 ms: 1 #
0.239000 -0.240000 ms: 8 ########
0.240000 -0.241000 ms: 3 ###
0.241000 -0.242000 ms: 5 #####
0.242000 -0.243000 ms: 4 ####
0.243000 -0.244000 ms: 8 ########
0.244000 -0.245000 ms: 7 #######
0.245000 -0.246000 ms: 4 ####
0.246000 -0.247000 ms: 1 #
0.247000 -0.248000 ms: 4 ####
0.248000 -0.249000 ms: 4 ####
0.249000 -0.250000 ms: 6 ######
0.250000 -0.251000 ms: 6 ######
0.251000 -0.252000 ms: 10 ##########
0.252000 -0.253000 ms: 2 ##
0.253000 -0.254000 ms: 7 #######
0.254000 -0.255000 ms: 5 #####
0.255000 -0.256000 ms: 4 ####
0.256000 -0.257000 ms: 9 #########
0.257000 -0.258000 ms: 7 #######
0.258000 -0.259000 ms: 13 #############
0.259000 -0.260000 ms: 11 ###########
0.260000 -0.261000 ms: 15 ##############
0.261000 -0.262000 ms: 18 #################
0.262000 -0.263000 ms: 20 ###################
0.263000 -0.264000 ms: 35 ##################################
0.264000 -0.265000 ms: 26 #########################
0.265000 -0.266000 ms: 9 #########
0.266000 -0.267000 ms: 13 #############
0.267000 -0.268000 ms: 13 #############
0.268000 -0.269000 ms: 11 ###########
0.269000 -0.270000 ms: 13 #############
0.270000 -0.271000 ms: 13 #############
0.271000 -0.272000 ms: 13 #############
0.272000 -0.273000 ms: 6 ######
0.273000 -0.274000 ms: 8 ########
0.274000 -0.275000 ms: 13 #############
0.275000 -0.276000 ms: 7 #######
0.276000 -0.277000 ms: 11 ###########
0.277000 -0.278000 ms: 8 ########
0.278000 -0.279000 ms: 11 ###########
0.279000 -0.280000 ms: 7 #######
0.280000 -0.281000 ms: 10 ##########
0.281000 -0.282000 ms: 13 #############
0.282000 -0.283000 ms: 8 ########
0.283000 -0.284000 ms: 9 #########
0.284000 -0.285000 ms: 22 #####################
0.285000 -0.286000 ms: 21 ####################
0.286000 -0.287000 ms: 25 ########################
0.287000 -0.288000 ms: 26 #########################
0.288000 -0.289000 ms: 36 ###################################
0.289000 -0.290000 ms: 52 ##################################################
0.290000 -0.291000 ms: 39 ######################################
0.291000 -0.292000 ms: 31 ##############################
0.292000 -0.293000 ms: 20 ###################
0.293000 -0.294000 ms: 27 ##########################
0.294000 -0.295000 ms: 19 ##################
0.295000 -0.296000 ms: 11 ###########
0.296000 -0.297000 ms: 10 ##########
0.297000 -0.298000 ms: 13 #############
0.298000 -0.299000 ms: 8 ########
0.299000 -0.300000 ms: 8 ########
0.300000 -0.301000 ms: 4 ####
0.301000 -0.302000 ms: 5 #####
0.302000 -0.303000 ms: 6 ######
0.303000 -0.304000 ms: 7 #######
0.304000 -0.305000 ms: 8 ########
0.305000 -0.306000 ms: 3 ###
0.306000 -0.307000 ms: 5 #####
0.307000 -0.308000 ms: 5 #####
0.308000 -0.309000 ms: 5 #####
0.309000 -0.310000 ms: 2 ##
0.310000 -0.311000 ms: 6 ######
0.311000 -0.312000 ms: 2 ##
0.312000 -0.313000 ms: 4 ####
0.313000 -0.314000 ms: 3 ###
0.314000 -0.315000 ms: 3 ###
0.315000 -0.316000 ms: 1 #
0.316000 -0.317000 ms: 2 ##
...
0.321000 -0.322000 ms: 2 ##
0.322000 -0.323000 ms: 1 #
...
0.324000 -0.325000 ms: 1 #
...
0.334000 -0.335000 ms: 1 #
...
0.340000 -0.341000 ms: 1 #
...
0.344000 -0.345000 ms: 1 #
...
0.411000 -0.412000 ms: 1 #
...
0.421000 -0.422000 ms: 1 #
...
0.563000 -0.564000 ms: 1 #


> SUCCESS

best latency was 0.154279 ms
worst latency was 0.562957 ms, which is great.


real 0m9.273s
user 0m0.012s
sys 0m0.000s



random time interval (from 6ms to 12ms) continuous ipMIDI packets train (optimized : windows CPU energy saving disabled)
root@debian:/home/studio/alsa-midi-latency-test/src# time ./alsa-midi-latency-test -o 128:0 -i 128:1 -R -3 -w 6 -r -S 1000

> set_realtime_priority(SCHED_FIFO, 99).. done.
> clock resolution: 0.000000001 s
> interval between measurements: 6.000 .. 12.000 ms

> sampling 1000 midi latency values - please wait ...
> done.

> latency distribution:
...
0.101000 -0.102000 ms: 30 ############
0.102000 -0.103000 ms: 29 ############
0.103000 -0.104000 ms: 45 ##################
0.104000 -0.105000 ms: 122 #################################################
0.105000 -0.106000 ms: 105 ##########################################
0.106000 -0.107000 ms: 125 ##################################################
0.107000 -0.108000 ms: 99 ########################################
0.108000 -0.109000 ms: 70 ############################
0.109000 -0.110000 ms: 53 #####################
0.110000 -0.111000 ms: 52 #####################
0.111000 -0.112000 ms: 50 ####################
0.112000 -0.113000 ms: 49 ####################
0.113000 -0.114000 ms: 48 ###################
0.114000 -0.115000 ms: 27 ###########
0.115000 -0.116000 ms: 24 ##########
0.116000 -0.117000 ms: 13 #####
0.117000 -0.118000 ms: 10 ####
0.118000 -0.119000 ms: 6 ##
0.119000 -0.120000 ms: 2 #
0.120000 -0.121000 ms: 4 ##
0.121000 -0.122000 ms: 5 ##
0.122000 -0.123000 ms: 1 #
0.123000 -0.124000 ms: 5 ##
0.124000 -0.125000 ms: 1 #
...
0.126000 -0.127000 ms: 2 #
0.127000 -0.128000 ms: 1 #
...
0.130000 -0.131000 ms: 1 #
...
0.133000 -0.134000 ms: 1 #
...
0.145000 -0.146000 ms: 1 #
...
0.150000 -0.151000 ms: 1 #
0.151000 -0.152000 ms: 1 #
...
0.153000 -0.154000 ms: 1 #
...
0.155000 -0.156000 ms: 1 #
...
0.157000 -0.158000 ms: 1 #
...
0.159000 -0.160000 ms: 1 #
...
0.161000 -0.162000 ms: 1 #
...
0.170000 -0.171000 ms: 1 #
...
0.174000 -0.175000 ms: 1 #
0.175000 -0.176000 ms: 1 #
0.176000 -0.177000 ms: 2 #
0.177000 -0.178000 ms: 2 #
...
0.181000 -0.182000 ms: 1 #
...
0.187000 -0.188000 ms: 1 #
...
0.195000 -0.196000 ms: 1 #
0.196000 -0.197000 ms: 1 #
...
0.325000 -0.326000 ms: 1 #


> SUCCESS

best latency was 0.100569 ms
worst latency was 0.325058 ms, which is great.


real 0m9.109s
user 0m0.004s
sys 0m0.012s





$ ./alsa-midi-latency-test -h
Usage: ./alsa-midi-latency-test -o client:port -i client:port ...

-o, --output=client:port port to send events to
-i, --input=client:port port to receive events from
-l, --list list available midi input/output ports

-R, --realtime use realtime scheduling (default: no)
-P, --priority=int scheduling priority, use with -R
(default: maximum)

-S, --samples=# of samples to take for the measurement (default: 10000)
-s, --skip=# of samples to skip at the beginning (default: 0)
-w, --wait=ms time interval between measurements
-r, --random-wait use random interval between wait and 2*wait

-x, disable printf real time display measurements,
improve time accuracy with VERY low latencies,
cancels the additional printf delay (<0.1ms) but
to compensate with -w option to avoid CPU saturation

-1, 1/10^1ms display precision from nanosecond accuracy (default)
-2, 1/10^2ms display precision from nanosecond accuracy
-3, 1/10^3ms display precision from nanosecond accuracy
-4, 1/10^4ms display precision from nanosecond accuracy
-5, 1/10^5ms display precision from nanosecond accuracy
-6, 1/10^6ms display precision from nanosecond accuracy

-h, --help this help
-V, --version print current version
Elia
User avatar
elia
Member
 
Posts: 124
Joined: Mon Oct 27, 2008 2:11 pm
Location: Italy , Padova

Previous

Return to DIY organ consoles / MIDI

Who is online

Users browsing this forum: No registered users and 1 guest