[LAD] ALSA MIDI latency test results are far away from reality

[Robin Gareus]

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
>