20 Apr
2014
20 Apr
'14
3:49 a.m.
IIUC we are not talking about the same alsarawmidi.
On Sat, 2014-04-19 at 18:18 +0200, Ralf Mardorf wrote:
jackd --sync -Xalsarawmidi -dalsa -r$sample_rate
-p$frames_period
^^^^^ ^^^^^^^^^^^^^
On Sat, 2014-04-19 at 19:47 +0200, Robin Gareus wrote:
jackd -S -dalsa -dhw:2 -r48000 -p64 -n2 -Xraw
^^^^^^ ^^^^^
Take a look at an older thread:
From: Devin Anderson
To: Paul Davis
Cc: Ralf Mardorf, linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] midi backend not working in qjackctl?
Date: Wed, 14 Mar 2012 10:00:50 -0700
On Wed, Mar 14, 2012 at 9:04 AM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
On Wed, Mar 14, 2012 at 11:52 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
The 'alsarawmidi' slave driver in JACK 2 does not have this problem.
It postpones the delivery of events based on the audio buffer size.
Back in April, when I requested MIDI latency/jitter test results for
the driver, I saw peak jitter results as low as 60 microseconds.
The 'seq' and 'raw' drivers attached to the ALSA audio driver still
suffer from this problem.
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
synthclone - http://synthclone.googlecode.com/
Especially in combination with Jack2's
-Xalsarawmidi you'll get zero
hw MIDI jitter, aka hard real-time.
I don't know if this is the new code that was added recently.
If its the old stuff then it absolutely is not zero jitter. You're
confused about the difference between "real time", "low latency" and
"jitter". The whole problem of the old code is that was absolutely
"deliver it as fast as possible" and that is precisely is what causes
jitter.