Seq66's MIDI timing completely falls apart at JACK buffer sizer larger than 128

[unfa]

Here's a 16th note blastbeat at 200 BPM I used to test this. I am using Geonkick to generate audio so the waveform should be identical every time (it plays internally-generated samples).

At buffer size 2048 the timing is completely broken:

At buffersize 128 - it seems good, but when you look closely at the waveform just before each transient you'll see that they differ and this is audible.

Here's 32 - audibly it's best so far, but we can see that it's still not perfect:

256 is the lowest usable imho but it's jittery:

For my work I usually need buffer of 1024 or 2048, as I do livestreaming and my DSP load is really high.

Here's 1024, which is the lowest feasible for me, but already will cause severe xruns:

It seems like the events are not properly scheduled withing each buffer and they get piled up at the end or start of each buffer cycle? I don't know how this works technically, but no other MIDI sequencer I ever used did this.

Here's the RaySession I used to test this. I'll require you to have RaySession, Carla and Geonkick installed to test:
unfa live 2022-09-03.tar.gz

RaySession allows to very easily change the buffer size:

Hopefully this can help :)

PS: I've tried changing JACK PPQN value from 192 to 2400 but it had absolutely no effect.

[falkTX]

looking at the code for jack-midi, there is a single call to write data at https://github.com/ahlstromcj/seq66/blob/master/seq_rtmidi/src/midi_jack.cpp#L375
the s_offset value being used there is always 0, causing events to lose their timing and thus introducing jitter.

reducing buffer size reduces the jitter because the 0 value will be closer to the target, by virtue of the buffer being smaller.
with a 8192 size buffer, a value of 0 means there are 8191 possibly incorrect values. with 128 there are only 127, with max deviation being 127 samples.

this is simply lack of event timing being present on the midi messages.

[ahlstromcj]

Thanks for the report and the input. I will investigate and get the fix into version 0.99.1.

I did try to duplicate this, and was able to get very choppy audio in qsynth by setting its audio buffer to 4096, in ALSA, JACK, and with other sequencers, but I think that's a different issue, and I was on the wrong track.

I will do a proper investigation soon.

Question: how would I impress event timing on the MIDI messages in JACK? They already have timestamps.

Thanks again!

[unfa]

Thanks! I was hoping maybe I'll be able to do a Livestream tomorrow with Seq66 to show it off, but I'll have to wait until this is fixed.

[ahlstromcj]

It will be awhile. I got geonkick and raysession installed, and extracted your tar.gz file to ~/Ray Sessions. But when I open the session, geonkick appears in Carla but qseq66 does not. (I also had to run "qseq66 --home ~/Ray Session/unfa..../config" separately to get rid of your MIDI ports and use what I had. So I still have some tinkering to figure out, and maybe a session issue to fix.) The saga continues....

[unfa]

Thanks! Yeah, I had some trouble making qseq66 run inside RaySession, though I think it was a bug in the latter.

[ahlstromcj]

So I gave up on your setup, and am making a manual setup, using either Carla or QjackCtl (trying both). I am stymied at trying to get any sound out of geonkick. I can try a kit and see the VU meter moving, but no sound. I have PulseAudo in play, but it doesn't matter if I direct the output to either of the PA Sources or to System playback.

I put all of the drums on ch 10 (9 re 0) just to simplify things.

Once that's working, how do you display the generated blastbeats?

Thanks!

[unfa]

I have recorded the audio to Audacity, but you could use x42 SiSco (Simple Scope) plugin to view the waveforms in realtime.

[ahlstromcj]

I have got close to being able to provide a sample offset. I can get rid of the major glitches when the frame size is 4096. However, I am pretty sure my calculation of "sample offset" is not quite right. Where can I find the definition of "sample offset". It's not defined obviously in the jack2 code. How does one calculate it, given the current frame number, the framecount in the MIDI output callback, the tick value of the MIDI event, and other parameters? Thanks!

…

-------- Filipe Coelho 07:38 Sat 03 Sep --------

this is simply lack of event timing being present on the midi messages.

[ahlstromcj]

Is there any function call a JACK client can make to determine the periods (nperiods) value? Thanks.

[falkTX]

I am not sure what you are confused about..
the process call is an audio block of X number of samples, where X = buffer size.
it is called at regular intervals, that follow the real passage of time.

so under 48kHz with 512 buffer size, we have processing with blocks of 512 samples, where roughly after 94 blocks 1 second will have passed (512 * 94 = 48128, which is bigger than the 48kHz sampling rate).
the 48kHz in my example here means there are 48kHz samples in a second.

for JACK MIDI, the "frame" just refers to the offset within the process function it is called within.
because the process is an audio block, you have 0 up to block-size-frames (512 in my example) of possible values the event is present on.

This is basically how all audio and plugin APIs work, when we deal with audio in blocks.

Sometimes events cross the process call boundary, where a note starts near the end of the block and goes on for a while until it stops in another block (and thus its duration is higher than 512 samples, which means 10.6ms at 48kHz).

[ahlstromcj]

I get all that. But where does the nperiods (e.g. 2 or 3) value come in to play? I'm not interested in audio at this point, just MIDI. Here's what seq66 does currently with my attempted fixes: - Adds the timestamp to the messages stored in the output port's ringbuffer. - In the process callback, extract the timestamp, which will be in units of MIDI pulses. - Use the timestamp, pos.frame_rate, pos.ticks_per_beat, and pos.beats_per_minute to translate the timestamp to a frame number. - Mod the frame number to be within the nframes range as returned by the callback. Does the nperiods value affect the frame numbers? I picked up bits and pieces of how JACK works by looking at source code and information from the internet, but I have not seen any coherent explanation of JACK MIDI framing. Also, will jack_transport_query() work on it's own, or do I have to have JACK transport enabled in the application in order get proper jack_position_t values?

[falkTX]

what do you mean by "nperiods"? the alsa value? if so, it is completely irrelevant here.

JACK audio and MIDI it is all sample-accurate and in the same thread, same way as plugins APIs do it.
the timing of the events is meant to be in sync with the audio, the "offset" means exactly the same regardless if using audio or midi.
How you reach to a precise audio-relative accurate offset is up to you. and it is not something exactly unique to JACK, so there is bound to be some info online about it. (it is the same situation as when one tries to add an audio/midi offset to a gui-generated event, typically a calculation based on current-absolute-time vs when next audio callback is expected)

jack_transport_query always works, if you get valid BBT information or not depends if there is a transport master supplying that information at any given moment or not.

[ahlstromcj]

Thank you! Very helpful information. Pretty much every sequencer application I have examined seems to make the calculation in a different way :-D, and sometimes very obscure to track down. Peace.