On 07/14/2010 07:58 PM, Ralf Mardorf wrote: > On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus wrote: >> On 07/14/2010 04:22 PM, Ralf Mardorf wrote: >>> Hi Robin :) >>> >>> On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote: >>>> On 07/14/2010 03:23 PM, Ralf Mardorf wrote: >>>>> [..] >>>>> 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 >>> >>> 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. >> >> I'm sorry; don't understand that. Are you getting [audio] x-runs or what >> is the problem using -p64 (or even -p32)? > > Yes there are lapse, even if there should be no messages about xruns. > >> I was hinting that the audible midi-jitter could be a result of >> midi-messages getting 'quantizied' to jack-periods. > > It seems to be like that. Take a look at my email with the > subject: > Correlation of alsa -p value and hw > MIDI jitter > >> 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".
It turned out I was using an ancient version of "a2j". > I did use Qtractor, but had the same issue when using Rosegarden a long > time ago. But we are talking about ALSA MIDI to the hardware > MIDInterface?! Originally i was only talking about JACK-MIDI apps. >>> 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? > > All kinds of dropouts, even the left and right channel seem to get out > of phase. Just running FluidSynth DSSI playing a kick and a rim-shot was > without audible failure at -p16, but I'm sure I won't be able to do > multi-trach recording with -p16. > >> >> 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. >> >> 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? > > On a todo list, but there seems to be a correlation to JACK audio. The idea is to remove all correlations. Otherwise it's very hard to find the problem. It looks like you're chasing [at least] two different issues: 1) ALSA / hardware jitter 2) qtractor/fluidsynth timing/sync Don't even start JACKd. just use 'aplaymidi'. or 'ametro' http://perso.wanadoo.es/plcl/ametro/ametro-en.html >> 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. > > C64 and Atari ST are stable, but there are some issues for e.g the > monitor. My VGA isn't slow enough for the Atari. I'll try to do it with > the broken SM124. > >> 'aseqdump' (at least version 1.0.22 which I currently use) does not >> print timing-info, 'kmidimon' does. You can also just use 'arecordmidi' and open it later in an editor. And finally: External-Keyboard or Sequencer -> PC -> External-Synth Use 'aconnect' or 'aconnectgui' to connect MIDI-in -> MIDI-out. There should be some latency but no recognizable jitter. If these 3 (amidiplay, amidirecord, ALSA midi-thru) do not work as expected, all other tests that mix external-hardware and software will be [more or less] useless. >>> 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. > > Thank you for your effort :). > >> >>> 'Read you later' today or at the latest on Friday. >> >> enjoy a good long week-end. > > Have a nice weekend too. I wish I could. It's only just Wednesday here, even though it's Bastille day. > I'll spend the weekend for Linux audio. > >> >>> Cheers! >>> >>> Ralf >> >> ciao, >> robin > > Cheers! > > Ralf > _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev