Am Freitag, 27. Oktober 2017, 00:52:15 CEST schrieb Markus Grabner:
> Then I compared the timing accuracy of Hydrogen's internal sampler with an
> external one (LinuxSampler connected via Jack MIDI). I created an artificial
> drum sample consisting of a single pulse and recorded the generated output
> with Ardour such that the timing can be evaluated with frame-accuracy when
> maximally zooming into the wave form view. With a sampling rate of 48kHz
> and a tempo of 108bpm, the samples had a distance of either 26666 or 26667
> frames, i.e., the error was less than a frame, which is optimal. However,
> repeating the same experiment with LinuxSampler, the individual samples
> were spaced either 26624 or 26880 samples from each other, which are both
> integer multiples of 256. I choose quite conservative settings for jack
> when recording (4 periods of 256 frames) since latency (21.3ms with these
> settings) can easily be compensated, while a single xrun can spoil the
> greatest take. So timing seems to be accurate only to periods, but not to
> single frames when using an external sampler via MIDI. The error caused by
> this issue is in the order of the range a note can be shifted by the
> lead/lag feature, i.e., not immediatetly noticeable when listening
> casually, but too large to be totally ignored in my option.
> To verify whether this is an problem with Hydrogen or LinuxSampler, I did
> two more experiments: using LinuxSampler as an Ardour LV2 plugin internally
> connected to an Ardour MIDI track, and using LinuxSampler as an external
> application connected to Ardour via MIDI. Both gave frame-accurate results.
> So let me summarize:
> *) Ardour + Hydrogen with its internal sampler produce frame-accurate output
> *) Ardour + LinuxSampler as an LV2 plugin produce frame-accurate output *)
> Ardour + LinuxSampler connected to Ardour via MIDI produce frame-accurate
> output
> *) Ardour + Hydrogen + LinuxSampler connected to Hydrogen via MIDI don't
> produce frame-accurate output
> I believe that the problem is in or near the method
> JackMidiDriver::JackMidiRead(), though I didn't spot any obvious mistake
> there.
I took a closer look at this method and found something interesting. The
variable "t" always counts from 0 to 2 and then starts again at 0. It is used
as the "time" parameter of the jack_midi_event_reserve() function. According
to the extensive documentation (see http://jackaudio.org/files/docs/html/
group__MIDIAPI.html#ga150dcdc37583e1ecbe0a6f16b6ac48a9), we learn that the
"time" parameter means the "Sample offset of event". This leaves some room for
interpretation at least, but I believe it means the number of frames w.r.t.
the start of the current period when the event should be triggered. To verify
this assumption, I did another pulse experiment with Ardour+Hydrogen
+LinuxSampler (see above), but modified the code such that 100 is added to the
"time" parameter of the jack_midi_event_reserve() function. Indeed the
distances between adjacent pulses were again integer multiples of 256, but the
absolute positions in time were delayed by exactly 100 frames.
So here is probably the bug: the "time" parameter should indicate the fraction
of the current period at which a note is to be played (which is a different
value for each note unless the time between two notes happens to be an exact
integer multiple of the period size), but instead the "time" parameter
periodically counts from 0 to 2. We need to somehow compute the modulo of the
absolute frame number when a note starts, and the period size, and pass this
number to jack_midi_event_reserve(). I will try to figure out how to do this
when I'm back from vacation next Friday. Do you have any comments or ideas on
this issue in the meantime?
Kind regards,
Markus
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
