.....

Not sure if this was mentioned, but I've encountered this before and I later found out (possibly thru this forum) that I had checked the "Record Cache" or something to that nature in the Audio Options dialogue.

I uncheck it, and it completely cured the "timing" issues I was having, including the quantized MIDI ones. HTH

Will

your offset correction will vary depending on your buffer size

FWIW, this is certainly true of some interfaces/drivers, but not all. A fixed manual offset works perfectly for all buffer sizes with my 1820m.

A fixed manual offset

What is your offset? Relatively small? Did you have big problems before you set the offset?

Is Centrace's latency an actual round trip latency? I assume so, but looking for confirmation.

Yes, it's the full round trip for whatever return path you make available - whether it's an analog patch, or an all-digital software loopback using the mixer applet (bypassing the D/A and A/D conversions).

I did a different kind of timing test, measuring the lag between executing a MIDI ON event and the start of a recorded wave from an external synth. This is different from a round-trip latency test, because it doesn't involve any playback processing or D/A conversion. It's also very easy to do.

In the following screenshot, the vertical line is the Now marker, which has been set to the start of the MIDI note. You can see that each recorded wave lags the MIDI note by a different amount. The only difference is the ASIO buffer size and whether the selected input is analog or digital. The ASIO offset has been set to zero for this test so there is no compensation.



Latencies are expressed in samples, e.g. "lat=122" means a 122-sample lag time. Multiply that by .0227 to get real time in milliseconds (1 sample = 22.7us at 44.1KHz).

As you can see, S/PDIF is faster, in some cases by as much as 3ms. That amount of difference surprised me at first (I was expecting about 1ms difference) until I realized that the digital path not only avoids the A/D conversion, it also avoids the D/A conversion within the synthesizer.

Another surprise is that the lag time is not directly proportional to buffer size. The delay is reduced as buffers are reduced, but not in a linear fashion. Under about 128 the benefit from buffer reduction reverses and lag times begin to increase. On my system, the optimal buffer size was 256 samples.

Surprise #3: note the frozen soft synth, which is actually ahead of the MIDI note by 47 samples.

ORIGINAL: bitflipper

I'd be very curious if anyone else did a similar test and got other/same results, especially any RME users.

My worst-case scenario (1024 buffer, analog input) had a 7.5ms lag - long enough to be a problem with short-attack instruments. I wonder if other brands of interfaces have less of this problem.

Jose?

That's actually a MIDI latency test which was extensively discussed in the MIDI Jitter thread. You know I would test this out for you but I sold my Roland XP synth some time ago in order to get my current MIDI controller (a Studio Logic VMK-188 Plus), so I won't be able to perform this test :-( I personally haven't read the whole 'MIDI Jitter thread' myself but I'm sure it will help you find an answer.

Happy 4th of July!!!

ORIGINAL: Jose7822

ORIGINAL: DH123

743 samples!!!!!! GRRRRHHHHHH!!!!

Time to redo some parts . . .

CRAP! This changes everytime I change my buffer size?

Yeah, I believe it does, specially if you're using WDM since it doesn't have latency compensation like ASIO. Just calculate the buffer size(s) you use for recording and write it down somewhere. Input the one you need in the buffers offset box and you're done. You don't need to calculate all of them since this doesn't apply to playback.

HTH

Interesting...I just tried it at a buffer size of 128 and 1024 and the offset was -65 both times. I thought it should be the same for every one...so do I need t ogo back and get a number for every buffer size to put in manual offset? Wow...changing buffer size is now going to be a chore if so...although those are the two i use 95% of the time so may be it's OK. I am using ASIO BTW and did notice the ASIO reported latency changed. I am going to have to experiment...

I'd be very curious if anyone else did a similar test and got other/same results, especially any RME users.

My worst-case scenario (1024 buffer, analog input) had a 7.5ms lag - long enough to be a problem with short-attack instruments. I wonder if other brands of interfaces have less of this problem.

I've share some results of this kind of testing in a number of other threads you may have seen. Basically what I found is that if your audio latency compensation is set up and working correctly, any variation in lag can be attributed to the variable transmission delay and response time of different MIDI interfaces and hardware synths.

I found my slowest hardware synth (E-mu UltraProteus) required an additional 6ms or so of compensation on top of the 1-2ms MIDI transmission delay, while others needed only 1 or 2 milliseconds more. I also found that real-time recording of soft synths by digital loopback required a couple milliseconds additional compensation to account for a MIDI transmission/processing delay between the input echoed MIDI track and the soft synth. In other words, it took just as long (maybe even a hair longer) to echo MIDI to a soft synth as it took to echo it out a physical port.

I found my slowest hardware synth (E-mu UltraProteus) required an additional 6ms or so of compensation on top of the 1-2ms MIDI transmission delay, while others needed only 1 or 2 milliseconds more.

So you're saying the lag time is mostly latency within the synthesizer itself? That kind of makes sense - although nobody ever seems to think about latency in a hardware device, you know it has to exist. I'm just surprised it's that slow.

Hi Bitflipper

At 960 ticks per measure, the maximum resolution at 120bpm is only 2.1ms

Actually, it's 960 ticks per quarter note, not per measure. At 120 bpm, that's 500 millliseconds/quarter note; 500/960 gives a MIDI resolution of about 0.52 milliseconds. Internally, Sonar can use 'hi-res ticks', which are 960 * 2^16 ppqn, if memory serves - that gives sub-microsecond accuracy, in theory. (At least, the MFX APIs support that kind of timing).

I am wondering now if this is a result of firewire buffering. Obviously, you can't send a separate FW (or USB) packet for every MIDI event.

Firewire MIDI uses isochronous packets (same basic packet type as for audio: a subtype of "Common Isochronous Packets"). The basic packet rate is 8KHz (1 packet every 125 microseconds) . Firewire bandwidth of MIDI is reserved, which means that other traffic cannot 'bump' MIDI traffic (which would cause jitter). This would theoretically support high-speed MIDI (e.g. 8KByte/second of MIDI data, rather than the 3KB/sec afforded by MIDI-DIN connections). However, for compatibility with MIDI-DIN interfaces, Firewire MIDI is rate-limited to 3KB /sec. Firewire MIDI and 'MIDI-DIN" have very similar jitter and "MIDI logjam" behavior, by design. (Firewire MIDI often has somewhat higher latency (w.r.t. a PC sequencer), due to the overhead of the Firewire stack).

USB MIDI is designed differently. First, it uses asynch packets, sent at background priority. This means MIDI packets can get bumped by other USB traffic (audio, disk transfer, etc.). Second, USB MIDI is not rate-limited. This reduces "MIDI logjam" smearing when lots of MIDI data is sent, and also makes Sysex dumps faster. However, it's quite possible to overload a USB-to-MIDI DIN output port (by sending more than 3KB/sec of MIDI data to the port. With USB 1.0, the USB 'heartbeat rate' is 1K, which means all MIDI data has at least 1 msec jitter (of course, it's usually more). I'm told USB 2.0 supports a faster packet rate, which in theory should allow jitter to be reduced.

In practice, good PCI MIDI interfaces have the least jitter, followed by good Firewire interfaces, with USB interfaces exhibiting the most jitter. A good USB MIDI interface probably has 1-2 msec peak jitter (but that's just what I recall from recent published measurements). A bad USB MIDI interface .... you don't wanna know....... Of course, a badly designed PCI or Firewire MIDI interface will also exhibit lots of jitter, but the worst interfaces I've personally seen have been 'budget' USB interfaces. (I do use an Edirol UM-550 and EMU 0404 USB interface for various things, but use Emu 1820M PCI MIDI ports for critical recording).

As for hardware synth latency - Jim Aiken did a Keyboard article on this back in July 1996. Jitter (for individual cowbell hits ) was in the range of 0.4 - 2.0 milliseconds, with latency ranging from 0.3 milliseconds (pretty good) to 1.5 milliseconds). This was for a number of Alesis, Ensoniq, Korg, Roland, Yamaha and Kurzweil modules. Under load (with a 6 note chord on beats 2 and 4), MIDI logjam effects were measured (the cowbell hit, 1 tick after beats 2 and 4, was delayed by the MIDI transmission time for 6 full Note On messages (~6 msec) - sometimes more).

HTH,

Jim

nice post, Jim. Thanks!

I can definitely hear out of groove-ness that results from just a few milliseconds... after ping-testing and moving my tracks by the right amount there's absolutely no comparison to how "musical" it feels when it's right on!

This is an important issue in the real function of recording music in Sonar I think- thanks for all the research you's guys are doing on it-
Ev

www.evanandnature.net

ORIGINAL: bitflipper
That's old-style DIN at 38.4kb/s. But no, that's still a potential MIDI note every 26us

Actually, old-style DIN is 31.25kb/s (because the UART used in most early MIDI interfaces was a Motorola 6850, with max clock rate of 500 KHz and a clock divisor of 16, in case you're curious).

And, given the that a MIDI note typically takes 3 MIDI bytes (2 when running status is used) -- at full capacity, a MIDI-DIN stream can send one note every 960 microseconds (320 microseconds per MIDI-DIN byte). Of course, if you're not sending MIDI at full capacity, notes can be placed more accurately than 960 microseconds. It was pretty easy (with 1980's technology) to schedule notes with jitter of one MIDI byte-time (320 microseconds timing accuracy, yielding jitter of +/- 160 microseconds). With some effort, I believe it was possible to schedule MIDI bytes with MIDI-DIN bit-time accuracy (32 microseconds, given the 10-bit frame used for the MIDI-DIN protocol).

Curiously, the use of running-status can actually increase jitter! If a MIDI note message sometimes takes 2 MIDI-bytes, and sometimes takes 3 -- it's harder to schedule dispatching a MIDI byte at 'just the right time', so that a complete MIDI note message is received when desired.

(The phrase "jitter...was in the range 0.4 - 2.0 milliseconds" - was that a typo? Surely jitter couldn't really reach over 1000% ??? ).

Nope, not a typo. It depends on when the complete MIDI message happens to hit within the internal processing loop of a given synth module. Some earlier synth modules were notoriously bad (10 msec jitter, or worse). Then again, some early USB MIDI interfaces exhibited jitter of 7-10 msec -- even more when the same USB 1.1 port was sending both audio and MIDI traffic.

To put things in perspective, the generally-recommended guideline for musically-acceptable realtime system performance (e.g. from pressing a controller key to the moment that a loudspeaker starts producing the corresponding note) is 10 msec latency max with +/-1 msec jitter max. Lower is better, of course. CNMAT (Center for New Music and Audio Technology) first stated those guidelines in the 90's, I think, but a number of folks within the computer-music community have endorsed them (including me). Sadly, a lot of MIDI systems don't meet those guidelines. The MMA does not endorse those guidelines, btw -- there are no official MMA guidelines relating to laten

The Keyboard article you mentioned suggests a maximum latency in the synth of 1.5ms, still too short to account for my 7.5ms latency and jitter, because there is no manufacturer consensus about what those values should be.

I'm not sure exactly what you were measuring -- could you describe your test setup again briefly?

It's pretty easy to check the latency of an external synth, by the way (if you have a MIDI thru box and are willing to do a bit of soldering). Take one MIDI Out circuit, and tack-solder a resistor onto the output pin of the opto-isolator (a 2.2Kohm value works well). Connect an audio jack to the resistor (and the ground pin of the opto-isolator) -- this should give you a pulse wave of around 1-2 volts amplitude, with a base frequency of about 16K. Then connect things like this:

DAW MIDI output -> MIDI Thru box IN
MIDI Thru box Out A (with resistor tap) -> DAW Audio IN 1
MIDI Thru box Out B -> Synth module MIDI IN
Synth module Audio Out -> DAW Audio In 2

DAW Audio IN 1 should capture the MIDI pulse train, while DAW Audio IN 2 should capture the synth output.
Once this is working, you can measure the latency between the MIDI messages (short analog signal bursts) and the start of the synth module note. (use a synth module program with a very percussive attack for best results).

- Jim

First , just to clarify, are you talking about the difference between the note-on time of a pre-existing MIDI event, and the beginning of the audio transient that is recorded as analog input coming back form the Yamaha?

Exactly.

Your explanation for the difference between analog and S/PDIF makes perfect sense. I just don't understand why the difference isn't consistent, or why it varies with the ASIO buffer size.

 Buffer size         Analog lag        S/PDIF lag      Difference
 1024                7.5ms               4.5ms           3ms (40% faster)
 256                 5.4ms               4.0ms           1.4ms (26% faster)
 128                 4.3ms               3.3ms           1ms (23% faster)
 

I would have expected the differences to be more consistent.

I wouldn't obsess over it except it complicates my tidy world. It means my ASIO offset value has to change depending on whether I'm recording a synth via analog or S/PDIF and what my buffer size is. Furthermore, the offset for recording straight audio is a different number altogether. I've had to make up a chart!

Thanks for lending your brain to my puzzle, Dave.

They do make sense I think if your interface has another significant constant delay from fixed additional buffers apart from the converters - either the communication bus or a dsp in the interface - that will also affect the s/pdif and create the same impression of diminishing returns from a lower buffer size. I would expect that once the buffer delay is less than the additional delays - the reduction would become negligible in its effect on the the total delay.

I think you might more easily quantify the additional delays by also trying different sample-rates. Fixed additional buffers will normally cause half as much delay when the rate is doubled - compare that with the delay obtained with the original sample-rate but half the driver buffer.

That may not be possible for s/pdif though, if your synths s/pdif cannot do at least 2 rates that differ by a factor of 2.

Jim