Does the MIDI input on an AI have the same buffer size and latency as the audio input?

[Wonks]

... or is it independent of it and have a lot lower 'latency'?

Hardware MIDI has a baud rate of 31.25kbps, so if you had constant MIDI data coming through it's not a lot less to deal with in processing terms than a 44.1kHz audio signal.

In general, MIDI data will come through in bits and pieces, so there's far less information to deal with, but if you were sending info on all 16 MIDI channels, presumably you could get close to full utilisation.

So does anyone know if the MIDI interface on an AI has a buffer, and if so whether it's directly related to the audio buffer size, or whether it just reads in a complete MIDI message before spitting it out, so worst case (for non-sys ex stuff) three message bytes (or 30 bits including the start and stop bytes), just under 1ms?

I'd imagine its the latter, as there's no A/D conversion involved to slow things down and, as messages aren't contiguous, a buffer would upset the timing of the messages; but I just wanted to check.

[James Perrett]

Certainly in Windows, MIDI uses a completely separate driver to audio. It has been ages since I've done any programming involving MIDI but I seem to remember that each complete MIDI message generates a Windows message to the application. I was doing a Midi Timecode reader so there were messages every quarter frame as far as I remember which means 100 messages every second at 25fps.

[Exalted Wombat]

Audio needs to be digitised, which involves buffering and hence delay. But this isn't the figure we're generally interested in when speaking of 'audio latency'. Rather the overall time taken to digitise the input audio, crunch it through the DAW's audio engine, maybe adding some effects, then send it out again as an 'input monitor'. A good interface can get this down to a few ms, but it won't be confused with 'instantaneous'.

MIDI commands reach the computer near enough instantly. But if the command is 'play a note using a software synth/sample player within the DAW program and send it out as audio' we still have to do this in the audio engine, and there will be a similar latency.

[Eddy Deegan]

I've done a little audio-related and rather more MIDI-related programming. To answer your question directly, "no"

The buffer size and latency of audio is completely unrelated to anything in MIDI world. Under Windows at least, unless using a custom driver, MIDI support in the OS is provided through Stream Buffers, MIDI Services or the (output only) Media Control Interface. Each of these is effectively a different API, provide different methods for I/O and none have anything to do with audio. Contextual info can be found here.

MIDI is far less demanding of CPU cycles than audio although DIN interfaces are limited in bandwidth as a rule (USB MIDI is invariably faster).

In any event MIDI and audio are different subsystems altogether. I'm sure there are buffers involved in MIDI and I've implemented them in user-world for my own purposes but for the most part this is handled by the OS on Windows.

I can't speak as confidently for Mac/Linux but I'd be really surprised if there was any principle difference although the APIs will differ.

[ajay_m]

The midi protocol, at least over DIN midi, is the last relic of the original teletype serial protocol (which was still commonly used by modems at the time midi was invented), where a start bit is succeeded by 8 data bits and then a stop bit for a total of 10 bits per character. Thus the latency is 10 bits which is well under 1ms just for the transmit latency. A device called a uart (universal asynchronous receiver transmitter) handled the serialisation and deserialisation of the data stream and modern microcontrollers still include uarts as circuit blocks to do exactly this.
Of course over usb there is no such restriction as the speed can be much higher and the framing bits are not required either.

[Folderol]

For MIDI you talk granularity rather than latency. Each complete data package takes about 1mS to transmit (running status is slightly faster) , but it's 'on demand' not a continuous stream so although it can't come in any faster, the actual arrival isn't necessarily in 1mS steps. It could be 1.3mS, 4.7, etc.
The result is you couldn't link this directly to the audio which is at a fixed (much faster) rate.

The hardware handles all of this and presents the computer OS with complete 2 or 3 byte messages which are then buffered. The music software is then free to interleave this with the audio as it sees fit.

Although MIDI over USB can be much faster, if it's from a meatware source it's still going to be pretty slow and erratic, so the same buffering is required.

[Folderol]

Forgot to mention something:
A lot of software only checks for MIDI at the end of each audio buffer. The really good stuff can insert it part way through processing the audio.

[merlyn]

... Hardware MIDI has a baud rate of 31.25kbps, so if you had constant MIDI data coming through it's not a lot less to deal with in processing terms than a 44.1kHz audio signal. ...

MIDI is a lot less data. Remember audio is 24 bit, so the bitrate is 44100*24 = 1058400 b/s = 1.06 Mb/s. And audio is usually at least stereo, so about 2 Mb/s.

USB MIDI uses packets which means there can be more jitter with USB, and as noted elsewhere, jitter can be worse than latency.

[Wonks]

I should explain a bit more. I’m interested in any timing differences between a hardware (5-pin DIN) MIDI event and an audio event appearing on a DAW timeline, especially if delay compensation is turned off to try and determine the pitch in-to-MIDI output conversion time of a Boss GM-800 (or an older GR-33 or SY-1000).

In theory it's easy:
1. Guitar pickup signal into one channel of an interface.
2. Hex pickup signal to GM-800 and then its hardware MIDI output into a hardware MIDI input on the interface.

Record both signals and compare the time difference between the start of the guitar pickup signal and the MIDI note produced by the GM-800 and that should be the PTM (Pitch to MIDI) latency value.

But reality steps in in the form of audio buffers (which are known) and MIDI signals (and whether they are mixed up in any audio buffer settings).

There is a three-stage process to get information into the DAW:
1. Processing within the AI.
2. Data transmission to the computer.
3. Distribution of the transmitted audio and MIDI data via their separate process streams to the DAW software.

Within the AI, there is enough computing power to send out the output of the A/D converter(s) on a sample by sample basis, but the receiving computer couldn't handle a per sample interrupt (especially with multiple channels being recorded at once), as well as running a DAW, effects, virtual instruments and its background tasks. So the output is buffered so the number of interrupts handled is far less.

Audio delays in the AI are minimal. There's the AD processing time, which will normally happen within 1/44100th (44.1kHz) of a second at the typical slowest converter setting these days, and the output value of the A/D needs to be read within the next sampling clock period.

The output is fed into the buffer for that channel and when the requisite number of samples have been fed into the buffer, the buffer is sent to the computer over the data transfer link, which is normally going to be a USB variant these days, though it could be Firewire or a PCIe transfer if an internal card.

Let's say there's a 32-sample buffer for audio. At 44.1kHz, that's only going to take 0.725ms to fill. Double that (1.45ms) for a 64-bit buffer.

A typical three byte 'note on' MIDI message (as has been said), takes just under 1ms to be sent and received, which is in-between the 32 and 64 sample buffer times at 44.1kHz. (As the sample rate goes up, the time taken to fill the buffer decreases). So at 44.1kHz, the MIDI message receive time is fairly similar to a 32 or 64 sample buffer fill time.

If we assume that the MIDI message is sent to the comms link once the full message is received (which some AI interface manufacturers infer is the case as they say the MIDI latency is 1ms), then the latency from the AI is similar.

The transmission times for a MIDI message (30 bits) and a 32 x 24-bit word depth sample (768 bits) will be different , but even at USB 2 data transmission rates (480Mbps), that is roughly 0.6µs and 16µs respectively, so almost adding nothing.

Which then puts the rest of the latency at the computer end. A good audio driver can have a latency of around 1.5ms for a 32 sample buffer, whilst others can be 4ms or greater.

Once the MIDI and audio data are in the computer, then they are just data and can be moved internally as fast as the computer allows, though the audio data needs to be extracted one sample at the correct clock speed by the DAW (or other Audio program using the data) and the MIDI message mapped to its time of reception at the DAW.

It appears from comments above that the audio and MIDI streams are handled by different processes within the computer, so the unknowns are how long each process takes to get the information into the DAW (via any buffers each process may have) and then on to the DAW's recording timeline.

Which is where my head starts to spin as I don't know what delays the MIDI data might have in relation to the audio data.

Going back to my requirement for determining the PTM latency time of a converter unit, could I simply look at the guitar signal start time and the MIDI note position start time, subtract the two time values, add on the reported input latency time (if delay compensation is turned off in the DAW) and then take off 1ms for the MIDI note delay?

I know reported input audio latency values can often be incorrect or estimates, but this method could also give incorrect values if the MIDI data was also a few ms out.

Yes, I know this is best done using scopes and probes to avoid any unknowns, but it's not particularly easy to test the GK-5 and GM-800 combination due to the digital signal connection between the pickup and GTM unit, and the fact that I don't have a GK-5 and GM-800, so it's a question of getting others to test who have them.

[Folderol]

I don't think you'll be able to get a meaningful answer. The single note test will only give the minimum possible latency (assuming the hardware isn't sending occasional control data, such as active sensing). Once there are multiple note and control messages (such as expression) all bets are off, as you won't know how many messages there are and which order they are being sent.

[James Perrett]

Wonks - I've only skimmed your post but I didn't see any mention of the A/D processing time. Nowadays A/D convertors work at a very high sample rate but downsample and filter the output digitally. This processing takes a few hundred microseconds so the output from the A/D will be around a millisecond or two late at 44.1kHz.

This can be an issue when you are combining outputs from different A/D convertors - there will be a slight time shift between them depending on the convertor type used.

[Wonks]

Wonks - I've only skimmed your post but I didn't see any mention of the A/D processing time.

I did, but I'd wrongly assumed it was just one sample period. Looking at the spec sheet for a Cirrus Logic CS 5381 (a reasonably high end converter), the total group delay (for 44.1kHz and 48kHz) is quoted as 12/output sample rate. I'm assuming the total group delay is the time between the signal being sampled and the chip outputting the sample value.

So for my 44.1kHz example it's 12/44100 or around 0.27ms. The dividend gets smaller for higher sample rates (9/output sample rate for 88.2kHz and 96kHz and 5/output sample rate for 176.4kHz and 192kHz).

Obviously other A/D chips may be different.

So whilst it's longer than I first thought, it doesn't add too much to the overall latency, especially when I'm thinking in whole millisecond values.

[Martin Walker]

May I refer you to my two-part SOS investigation entitled: The Truth About Latency?

https://www.soundonsound.com/techniques ... ncy-part-1
https://www.soundonsound.com/techniques ... ncy-part-2

Now it may have been written in the dark ages (2002), but I suspect much of it is still quite relevant, particularly relating to MIDI latency, whose real-world values I measured using a specially modified MIDI cable:

Martin

[Folderol]

Wonks, I think you're not taking into account buffer size.
For audio the latency will be the sample time multiplied by the buffer size. The buffer has to be filled before it is transmitted. Hence the smaller the buffer the shorter the latency, but at a significantly increased CPU load.
This is still only the theoretical value, and doesn't take into account what else the hardware and and audio interface is doing.

The most reliable way to test this (purely for audio) is round-trip testing where you link an input to an output and run software that sends a signal and measures the time it takes to return. The result is instructive and sometimes depressing! That's before you take into account the vagaries of MIDI.

[Wonks]

I did take into account buffer size.

ATM I’m not interested in round trip latency, just trying to ascertain if you can use a DAW to time within a ms or so the GTM conversion latency. Which mainly depends on the audio latency and any MIDI latency/jitter within the computer. This is the biggest unknown for me. From Martin’s tests all those years ago it was quite considerable, but I’d expect things to have improved over time as computers have got faster. But that may or may not be the case.

[James Perrett]

Looks like Martin's bodge cable would do the trick - both the raw guitar and the MIDI signal are recorded in the same data stream so you can easily measure the delay.

[Wonks]

Yes, that would seem to be the best answer.

I could knock one up here and simply compare the MIDI message with the MIDI ‘audio’ through my system.

[merlyn]

First what I would think what is a more illuminating test is how much delay there is between the straight guitar and the GM800's internal sounds, as that is how most people will use it.

Second, the reference here is a GM800 vs a keyboard controller. What's relevant is how much delay a GM800 adds compared to a keyboard controller. Recording the audio out and MIDI out of a keyboard synth is the reference point that isn't going to be bettered. The delay between the audio and MIDI of a keyboard synth includes all the possible overheads.

GM800 tracking delay = (GM800 delay) - (keyboard delay)

You'd probably need averages of a few values.

[Folderol]

Good point!

At best it's it's Audio ->MIDI -> Audio
Whereas with a keyboard it's Switchdata->MIDI-> Audio

[Martin Walker]

Looks like Martin's bodge cable would do the trick - both the raw guitar and the MIDI signal are recorded in the same data stream so you can easily measure the delay.

Exactly - here's the first screenshot from Part 1 of that article showing exactly this:

[merlyn]

With what Wonks is talking about, the audio would be first, followed by MIDI.

If we're going to use a DAW as a measuring instrument, then we have to calibrate it. Wonks is wondering how much latency is added to MIDI on the way in, by hardware, drivers, other miscellaneous garbage ...

To calibrate a DAW to find out how much delay there is between a MIDI keypress and the MIDI data arriving in the DAW put a mic on a MIDI keyboard, and press a key with a pencil/small screwdriver. Record the audio and MIDI. The delay between the two is the baseline MIDI delay that can now be factored out when measuring the tracking delay of a guitar synth.

Using Martin's lead would also be worthwhile, but it will make the GM800 figures look worse, as it doesn't factor out the baseline delay.

[Wonks]

Well, I didn't want to butcher any of my decent MIDI cables so I just went and ordered a cheap double pack from Amazon without thinking.

And they came with very moulded-on cables, with plastic filling up all the space in between the pins. I tried taking one apart today and gave up.



So I've now ordered a cable with removable metal-cased connectors, which should arrive tomorrow.

[merlyn]

I don't know why your focus is on MIDI. It's like you're using practice to work out the theory so you can say what it's like in practice. Using the MIDI out only of a GM800 is throwing away 90% of the functionality. Is this so you can make a like-for-like comparison with the Triple Play?

What's relevant to a player is always the audio. What's relevant is the time between hitting a string and the sound of the synth appearing.

The best case for the GM800 is using the internal sounds. A like-for-like comparison with the Triple Play has to include the output latency of whatever synth is being used as a sound generator. It's always the audio output that matters in practice.

Best case GM800: straight guitar vs internal sounds (both audio)
Best case Triple Play: straight guitar vs synth output (also both audio)

One way of thinking about it is that GK is a guitarist's equivalent of MIDI.

[Wonks]

I'm focusing on MIDI here because I'm looking to the answer for a specific question.

What delay is present in getting a MIDI signal into a DAW and if there is a significant delay (milliseconds instead of microseconds), is it affected by the audio buffer setting at all.

[Wonks]

I've given up on this. I made up my MIDI sniffer cable and could certainly record the MIDI signal clearly, but I'm using Cubase 8.5 (I got 9.5 and hated the moveable windows so have stuck with 8.5) and it's basically moving the start of the MIDI message to a subset of the BPM grid (but seemingly not note off). Zooming in, Cubase is always shows a grid line in bars and beats mode at the start of each MIDI note. So sometimes the MIDI track signal is a few ms after the audio input MIDI signal, and sometimes it's a bit before it.

Likewise with 'note off' info. The MIDI track 'note off' is often shown before the hardware 'note off' starts.

I've tried it with and without the latency compensation turned on and off but it made no difference.

So as I can't get any reliable timing figure, there's no point progressing this much further.

The difference is never much more than a couple of milliseconds, so any delay is relatively minor, but it's not really good enough to see if the MIDI track message position is affected by the audio buffer settings (or not).