To reduce MIDI jitter for apps such as .e.g Qtractor, jack2 provides the "-X alsarawmidi" option sine many years and in the meantime jack1 got something similar, too. To reduce MIDI jitter, there are other issues to consider, too, the kernel, the timer and what kind/s of interface/s is/are used, let alone the mobo.

What confuses me is that the Ardour manual recommends a2jmidid for all jack versions except recent jack1. This could of course be a case of "NIH". I suppose we are going to need some numbers. -- View this message in context: http://jack-audio.10948.n7.nabble.com/Considering-JamRouter-a-low-jitter-MI… Sent from the Jackit mailing list archive at Nabble.com.

On Wed, Jul 12, 2017 at 7:45 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: Good catch. In my experience, Ardour's manual isn't always up-to-date. NIH is definitely not something I think of about when Ardour is mentioned. It has always used lots of 3rd party libraries, bleeding edge very often. Besides, Paul Davis is a very experienced programmer who I have very much trouble seeing as a person who would re-implement something unnecessarily.

I>t has always used lots of 3rd party libraries, bleeding edge very often. Thank you for sharing your perception on that! I phrased that poorly- I didn't mean to ask so much whether JamRouter had been dismissed out of hand, I meant to figure out whether it may have been evaluated but dismissed for some kind of development process related reason. tentative conclusion that JamRouter has not been evaluated yet by the Jack community, most likely because it is a late arrival[1], there is an existing solution, and the likely presence of other pressing issues. [1] it was mostly developed in 2008 as part of phasex, but is only standalone since 2015 -- View this message in context: http://jack-audio.10948.n7.nabble.com/Considering-JamRouter-a-low-jitter-MI… Sent from the Jackit mailing list archive at Nabble.com.

Ah yes, build a better mousetrap and the world will beat a path to your door. But it might take years. The same might go for the GTK phasex synth by the same author that's been around and had accurate MIDI since 2008, as mentioned above. Sounds like all the synths on this track except the leads, which are hardware (Virus). https://soundcloud.com/dejavuslip/brand-new-day-v011 No distribution packages but builds fine and looks beasty. -- View this message in context: http://jack-audio.10948.n7.nabble.com/Considering-JamRouter-a-low-jitter-MI… Sent from the Jackit mailing list archive at Nabble.com.

Unfortunately, the author of JamRouter and Phasex has been "missing" for some time. By missing I mean absent from the Internet. He also disappeared in the past, then re-emerged for a brief time when he announced updates to Phasex and apparently pushed JamRouter to github. Then he promptly disappeared again. In the process, he left Phasex in a somewhat broken state and has since stopped responding to issues in github or other attempts at communication. So keep in mind that code in his repos is apparently at this point in time largely abandonware unless someone forks and continues development. On Fri, Jul 14, 2017 at 7:52 AM, Carlo Capocasa <carlo(a)capocasa.net> wrote:

On Thu, 13 Jul 2017 15:43:50 -0500, Chris Caudle wrote: +1 Let alone that in the past we seemingly noticed that I was the most nitpicking person regarding MIDI jitter ;), since I'm used to C64 with click sync to tape and Atari ST synced via SMPTE to tape, programming for the C64 myself in Assembler. I'm sceptic regarding the "sample accurate" sync. For the C64 computer we programmed directly using the hardware without layers and by turning of maskable interrupts using the SEI command of the 65xx chips. For PCs this is much more trick and has got much to do with good luck regarding the used hardware. IMO phasex is one of the best sounding virtual synth available for Linux, but it was provided for a very long time with a 0 Hz bug ;). DC offsets aren't fun. It wasn't a minor bug.

Oh that's just perfect it would appear that you're exactly who I was looking for. So in your opinion, JamRouter may or may not live up to its claims, at least when not using an exact replica of the author's setup, and may be prone to unexpected behavior. I already noticed that- I had to remove some signal handlers that aren't usually listened for on posix to get it to launch. Glancing at the codebase, while it's not terrible, I don't really see the author wasting a lot of time debating the finer points of scoping. If it's not too much trouble, I have an old school Hammerfall hooked up to a W530- could you kindly use your clout as nitpicker-in-chief to define approximately what kind of data and how much of it would satisfy you to make a reliable initial jitter comparison benchmark of, say, current jack1 and JamRouter? Would this do? https://github.com/koppi/alsa-midi-latency-test If you already have your preferred command-line switches for your favorite test program handy, all the better. Now, I will get off your lawn. Carlo -- View this message in context: http://jack-audio.10948.n7.nabble.com/Considering-JamRouter-a-low-jitter-MI… Sent from the Jackit mailing list archive at Nabble.com.

Hi Carlo, I'm tired of discussing this issue and I guess a lot of people prefer that I stopped discussing it ;). I found this one from 2015: http://linux-audio.4202.n7.nabble.com/MIDI-jitter-Was-outfitting-a-computer… And this one from 2010: http://lalists.stanford.edu/lad/2010/07/0189.html Note, I didn't read it again, so I don't know how useful or useless it is. I found this one where I was whining about another issue, but I claimed that "Jack MIDI latency test is ok", much likely it should read "ALSA MIDI latency test" ;). It looks like I already unbound an USB port sharing an IRQ with the HDSP. On my new mobo I can't do this, but the shared IRQ seems not to affect the HDSP at all. I changed my hardware, my current setup looks like this: [rocketmouse@archlinux ~]$ amidi -l Dir Device Name IO hw:0,0 HDSPMx579bcc MIDI 1 IO hw:1,0 TerraTec EWX24/96 MIDI IO hw:4,0,0 Scarlett 18i20 USB MIDI 1 apart from this I switched from an around ten year old AMD machine to an Intel machine, so now a perhaps better timer is available, let alone that I can use a lower audio frame value when launching jackd, which seemingly has impact on the midi-audio-sync-accuracy, too. Actually the audible issue did arise, when I tried to record one external MIDI instrument after the other, if all were recorded at the same time, it was more or less ok. I didn't use my new machine for critical MIDI recordings, maybe I will do during the German North Rhine-Westphalia summer holidays from 2017/07/17 to 2017/08/29. I'm working in childcare, so I have holidays myself at the moment. Regards, Ralf

Btw. jackd at least works perfect within the Linux environment, when not using external gear. I could write about a serious issue when using audiobus 2 audio sync to MIDI on my iPAD. I didn't test audiobus 3 and I unlikely will do, instead I switched to AUM and Inter-App audio. I guess the best bet on all platforms is to go with an all in one DAW and to use MIDI plugins instead of external MIDI gear. On no platform virtual MIDI synth could compare to the real oldish once, but at least on my iPAD they come close enough to decide against e.g. the real Oberheim and instead use the virtual Oberheim. Unfortunately we don't have that choice on Linux. My current experiment is to use the iPAD and it's virtual synth (sometimes by using samples of my real synth, too ;) and then to export/import to Ardour. I even can't stand Hexter compared to my first generation metal case DX7 ;). However, we always should distinguish between the fun and sound orgasm when playing a real synth and what is really needed for a mix. In the end mix a virtual synth usually could replace the original synth, just when playing them live the virtual usually sound like crap compared to the originals. -- Vote for apulse! echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ') Votes: 85 Updated: Sat Jul 15 19:04:14 CEST 2017