Yes, but that's an irrelevant point. Jitter is a problem only if/when a human detects it. Roland did studies that revealed that, even among musicians, humans can't detect timing discrepancies of less than 3 milliseconds. So if your jitter doesn't repeatedly and frequently introduce bigger delays, it's irrelevant in practice. The same is true of latency. So the ideal solution is to get that buffer size as small as possible, and reduce any "DSP processing overhead" to a minimum. And of course that goal is made harder if you're using a I/O layer that, by design, separates the user-space i/o code into another process from the dsp user-space code. Of course, I mean things like jack-midi (people, it's bad enough that Linux has 2 different midi api's, including one -- Alsa Seq -- which suffers from the aforementioned design. Now you want to proliferate another one that does the same? I'll say it right out. This jack-midi shite is ridiculous, and will only make developers regard linux audio/midi as even more fragmented and inconsistent than it already is, thanks to the ridiculous redundancy of too many audio servers. Kill this jack-midi nonsense NOW. Kill it. If you need jack-midi to add midi support to your app, then you don't understand how midi works, much less know how to add support for it. KILL JACK-MIDI! In fact, kill all of jack.)raboof wrote:Isn't taking into account timestamps needed to prevent jitter?
And in the context of BackupBand, I say "So?". I'm not dissatisfied with my system's MIDI-to-audio performance. I've been using BB on weekly gigs for 8 years now. No one ever complained about timing. Haven't heard that from endusers either. And I hope never to hear someone say:raboof wrote:If you don't timestamp and just trigger the MIDI audio at the beginning of the next buffer, then MIDI messages that arrive close to the beginning of the previous buffer have a higher latency than MIDI messages that arrive close to the end of the previous buffer.
My response will be "Really?".When i click on BB's chord chart, things play fine. But my midi keyboard is another story. I connect it to my computer via a real 31khz baud interface because I don't trust usb's vastly, vastly, V-A-S-T-L-Y faster transfer rate due to hearing some urban tales about what a huge problem midi jitter supposedly is. And to avoid this great plague, I set my software to use Alsa Seq api (instead of raw midi), which inflicts an unnecessary process context. Then I run it through some "bridge" (daemon that introduces another unnecessary process context) to repackage my midi data into "jack-midi" format. All so I can use software written by some misguided dude who used jack-midi instead of raw midi because he too thinks the former is the right way to deal with jitter and latency. But now my midi gear is giving me problems.
Silly me. BB doesn't have all those fun jack things to play with like periods, and number of buffers, and bridges. It has only a "buffer size". I set it one day, and I guess I just forgot to worry about jitter and latency during the past 8 years of gigging.
I don't. Seems I'm missing out on life's great adventures.How do you deal with this trade-off?