14 Jul
2010
14 Jul
'10
5:31 p.m.
On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
Aha, by this we can infer that your problem is ALSA or kernel/timing
related.
To verify this, take everything up from there (eg. qtractor, fluidsynth)
out of the picture for now.
1) Use 'amidiplay' to send a some midi-song directly to your
drum-module. -> Is there still audible jitter?
2) Do you have a Hardware MIDI Sequencer? Have it play a simple
metronome beat and dump incoming MIDI-messages. See if the timestamps of
each midi-note-on message are identically spaced.
'aseqdump' (at least version 1.0.22 which I currently use) does not
print timing-info, 'kmidimon' does.
Hi Robin :)
On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
I'm sorry; don't understand that. Are you getting [audio] x-runs or what
is the problem using -p64 (or even -p32)?
I was hinting that the audible midi-jitter could be a result of
midi-messages getting 'quantizied' to jack-periods.
A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but
simply processes all queued midi-events on each jack_process_callback()
will result in the symptoms you describe (snare & kick on the same
beat). One example of such an app is "a2j".
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
A good argument, because when I made tests in the past for the USB MIDI,
things become better at >= -p256 (when I had this Windows test install
latency for the EWX 24/96 audio was less high than for Linux). The
problem here is, that I need at least -p512 and even than I'm not safe
regarding to issues for JACK audio, that's why I used -p1024 instead of
-p512. For a test -p64 should work, but when recording music I would
need to increase it step by step until a minimum of -p512. [..]
AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
Any hints how to solve this are welcome.
Did you try to start jackd with -p64 instead of -p1024 IIRC when I did tests for the USB MIDI with -p64 or
even -p125 (I'm not
sure) it theoretically did work, but this isn't a solution, because at
some point JACK audio will fail.
How does it fail? x-runs?
JACKd works quite robust here with the UA25 and FA101 at 64fpp.
using
JACK-midi, I've encountered a similar issue with fluidsynth always
synchronizing note-start/ends to jack cycles.
Simply lowering the frames-per-period got me playing again so I did not
check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
At least FluidSynth DSSI (host is Qtractor) is able to play in unison
with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
machine. Just 'in unison' for virtual synth to hw synth there sometimes
is more delay, but just an early reflection like effect.
Note! It was hard to groove when I connected the master keyboard to ALSA
hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
drum module. Directly connecting the master keyboard to the drum module
there were no issues. I need to do something else now, but I take time off.
From Friday
(perhaps earlier) until next Sunday noon I could spend the whole days
for this MIDI issue only.
Resume:
I assume that -p64 would solve this 'looooooong early reflection like
effect/async', but then hard disk recording will become impossible.
The target is, that Linux at least replace the Atari ST as sequencer +
an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
would become impossible.
I'm pretty sure that you can get a stable 64fpp setup, but one thing at
a time. let's keep this thread to MIDI just now.
'Read you later' today or at the latest on
Friday.
enjoy a good long week-end.
Cheers!
Ralf
ciao,
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42