latency too high

[Wouter1]

There seems much more latency than expected.

[Wouter1]

TomDrinkwater reported

When you monitor through the DAW you would expect the latency to be around the round trip latency of 7.2ms which should be hardly noticeable, but in fact the round trip latency in this situation (from playing a note to hearing it back in the headphones) seems to be more like 54ms which is definitely noticeable.

[Wouter1]

TomDrinkwater reported

I did another round trip test.

I took a track or recorded audio and routed it out of channel 2

I then took a TRS cable and plugged it from channel 2 out to channel 1 in.

I recorded the audio on channel 1.

it was recorded 137ms behind the original track! It was also phase reversed.

I’m trying to think through what reaper does with latency compensation, but even with no latency compensation on recording it should be no more than the input plus output latency behind.

[Wouter1]

TomDrinkwater reported

I did some more round trip tests connecting the output directly to the input.

i got 44ms at 32 samples, 100ms at 64 samples, and 160ms at 128 samples

all phase reversed

I did the same test with my alesis photon 25.

3ms behind and not phase reversed.

the alesis is a usb "class compliant" device that works directly with core audio. With the alesis reaper reports 2.4/2.4ms latency at 64 samples, though this may not be accurate - it is consistent with it looping at 3ms behind with reaper compensating for the input latency but not the output latency, as you would expect.

so something is definitely wrong with the emu driver.

any suggestions what test to do to narrow it down?

I’m definitely not noticing such very high latency when playing a plugin synth through the emu, so I suspect the problem is with the input/recording side of things...

[Wouter1]

Thanks for all these reports. Yes definitely something looks wrong.

The idea of a loopback cable is good. Maybe I have a fitting cable somewhere.

i got 44ms at 32 samples, 100ms at 64 samples, and 160ms at 128 samples

Makes not a lot of sense to me. I think we should start at that 137ms.

[Wouter1]

Tom, this was all measured at 44.1kHz rate?

[Wouter1]

at 44k we have a 8192 sample buffer and 4 channels= 2048 samples. So even if we were lagging behind the full ring size it would be only 46ms. 139ms means we have to be THREE times our buffer size behind which is not possible

Therefore I think something else is going on here, like the start time stamp of recording and plyaback

[TomDrinkwater]

some points

• I think the problem is the input buffer not the output, because when I play a VSTi from a midi controller (not connected through the emu) then I don't get high latency
• I could not reproduce the 137ms - the reproducable results are the later ones
• the latency changes in proportion to the DAW buffer size. but much larger than it should be
• since the figures are consistent with the input latency being too large by one order of magnitude, I wonder if there could be a misplaced decimal point in some calculation, I guess we can always hope it is so simple, even if that is unlikely!
• multiple loopback tests show similar latencies at each buffer size, but not identical.
• all my recording latency testing so far is at 44.1Khz

If I can think of a way to test input and output latency separately I will do so, I think i would need a second computer and interface... this would be a bit of work to set up, so I hope we can find a problem without such detailed testing.

[Wouter1]

Thanks! Good to know we should focus on the 44ms at 32 samples, 100ms at 64 samples, and 160ms at 128 samples. I'd like to do a small test if this is related to the initialization procedure of the input channel. I'll compile a test version of the kext tonight and post it here. Maybe you can then test that and report back if that changes the input latency

[TomDrinkwater]

I'll look forward to trying it. I had a quick look through the code. There's a lot more of it than I would have expected and it seems complicated for the task. Are all usb drivers this complex? I guess it would be simpler if it was just for one device rather than several different ones. There seem to be a lot of workarounds with the usb input jitter. I wonder how it is handled in other USB devices. Anyway I'm impressed you got it working - I was lost!

[Wouter1]

Tom,

I changed the init procedure from 5 to 10 cycles for testing. If my hunch is right, the latncy will roughly double with this version (just to test if this is the problem) .

• download and unzipping the latest driver zip file
• remove the old EMUUSBAudio.kext from the folder
• rename EMUUSBAudio test.kext to EMUUSBAudio.kext
• run the kextInstall

Could you please try this ext and see what the latencies are now?

[Wouter1]

. I had a quick look through the code. There's a lot more of it than I would have expected and it seems complicated for the task. Are all usb drivers this complex?

The code is a copy from an existing driver that was even more messy. I tried to clean it up but only got so far. Also I think there is code that I suspect is not even used anymore but it's quite hard to tell what will happen on different EMU devices as I can't test on them so I left the code in.

But yes there ARE quite some things under the hood that a normal user would not expect or think of.

Notice that this is not a "usb driver", this is an audio driver. It builds on top of the system's USB driver but it's specific for the EMU .

[TomDrinkwater]

yes I understand about it not being a "usb driver" but it is structured around the issues inherent in the usb system, specifically the 1ms blocks (polling rate? what is the correct term for the 1ms limitation ins USB?) so that is what I meant.

to clarify, the driver translates between 2 other layers of software, the osx coreaudio system, and the osx usb hardware driver, is that right?

It seems like it would be far better for those 2 parts of the OS to talk to each other directly! I guess that is what happens with a "class compliant" device. We can't change that now though. It is a shame that emu didn't just make their interfaces class compliant since the hardware is so good, but as we see the software is messy.

Anyway, I will test your new version now, and report back. Have you tested it yourself and does it do what you expect on your hardware? or is there a reason you can't test it yourself?

[TomDrinkwater]

the new test kext does not load at all.

I can't see any obvious EMU related errors in console...

however I did some more testing with the old kext, and got different results. I will now try to replicate my different results with the old kext and report back.

[TomDrinkwater]

sorry forget that! - my mistake! new kext loaded, proceeding with testing!

[Wouter1]

what is the correct term for the 1ms limitation ins USB?

Yes polling rate is the term

to clarify, the driver translates between 2 other layers of software, the osx coreaudio system, and the osx usb hardware driver, is that right?

I don't know exactly. This driver is just below coreaudio but I also read about the HAL layer that might be on the user's side between coreaudio and the user's app.

It seems like it would be far better for those 2 parts of the OS to talk to each other directly! I guess that is what happens with a "class compliant" device.

"class compliant" only means that the driver is already built into the OS. This does not necessarily improve the situation, I suppose these class compliant devices STILL rely on the USB layer and hence are bound to exactly the same limitations as the EMU driver has.

It is a shame that emu didn't just make their interfaces class compliant since the hardware is so good, but as we see the software is messy.

What may be class compliant with OS10.9 might not be class compliant anymore with OS10.10? So I supose this does not really help. Remember that the EMU is many years old, from the 10.1 era when class compliant audio maybe did not even exist. Again I don't know too much about this but we need more info before starting to point to someone

Have you tested it yourself

No I had literally 10 minutes to make this fix. No testing was done. I can't measure latencies either so it would not make sense to test other then to ensure it's still working.

[Wouter1]

the new test kext does not load at all.

Yuk, that's what you get if you have no time at all. Sorry for that.

[Wouter1]

sorry forget that! - my mistake! new kext loaded, proceeding with testing!

Ah glad to hear that :)

[TomDrinkwater]

OK here's my results. the latency does not correspond with the buffer size, it changes but not predictably.

however remember that reaper is compensating for the size it thinks the input buffer is, so the compensation will change with the DAW buffer size. So these results show the difference between the reported latency and the actual latency, not the absolute real latency.

i did some of these tests twice, whenever i did the same thing twice in a row the results were the same, but when I change the DAW buffer size and test and then change back and retest a previous buffer size again, i get a different latency.

all tests 44.1khz loop emu out to emu in with a cable.

results with the old driver: 32 samples - 98ms 64 samples - 79ms 128 samples - 134ms 256 samples - 126ms

results with the new test driver: 32 samples - 59ms 64 samples - 182ms 128 samples - 68ms 256 samples - 10ms retest with 128 samples 107ms retest with 256 samples - 73ms retest with 32 samples - 155ms retest again with 256 samples - 119 ms

all these figures are just looking at the offset in reaper, they may be out by 1-2ms since I just manually select the range of the offset and look at how many ms the selection is. If we get to lower latencies and need to test more precisely, I will zoom right in and check exact samples offset, but being that precise is slower.

[TomDrinkwater]

"class compliant" only means that the driver is already built into the OS. This does not necessarily improve the situation, I suppose these class compliant devices STILL rely on the USB layer and hence are bound to exactly the same limitations as the EMU driver has.

yes this is how I understand it too. The class complaint way is a middle way. Truly professional equipment makers who are willing to spend a lot on development and maintenance can get better performance with their own drivers, maybe even bypassing coreaudio and/or the system USB. (most use coreaudio for convenience though) But for budget equipment and low development budgets class compliant can be good as it relieves the manufacturer of the responsibility to maintain the driver. So class compliant is not the best, but it is better than an unmaintained proprietry driver as we have here.

My class compliant devices work on Yosemite. It does rely on Apple not breaking things to be sure... which is certainly a risk. They broke lots of other things with Yosemite. However I think the whole point of class compliant is that it is supposed to be a standard that is fixed.

[TomDrinkwater]

all these tests were done with the driver set to 2200uS in the plist.

should I do some with the default 4200 as well? do you think it will change it?

[Wouter1]

Tom, many thanks for testing all these configurations. It looks like

• the old and the new driver basically are behaving the same. So this is probably not due to the initialization cycle. The randomness also votes against the init cycle whcih is always the same.
• the latencies seem to be completely random in the range approx 0-200ms.

I have to think about this, particularly where this randomness can be coming from.

[Wouter1]

should I do some with the default 4200 as well? do you think it will change it?

I don't expect it has an effect but you never know. If the effect is 4.2ms on an average of 100 it will be very hard to show that there is an effect anyway.

[TomDrinkwater]

I don't expect it has an effect but you never know. If the effect is 4.2ms on an average of 100 it will be very hard to show that there is an effect anyway.

that is what I thought, unless there is a multiplier effect somewhere.

if you can think of any more tests for me to do, let me know.

I will try to replicate these results in another DAW, when I get time. I am familiar with reaper so trying in others is slower.

[Wouter1]

Maybe this is a consequence of too hard protection of the read stream from jumping around when the coreaudio requests so. I will try to relax this protection and see what it does.

[Wouter1]

Tom, I have uploaded a new EMUUSBAudio test.kext. This time with a fix in the input. Could you be so kind to give this a try and check the latencies? I did a brief test at 96kHz where it seems to work ok - I'm not getting READ HICKUP messages while running the EMU (except possibly one time at startup). Maybe you can also check that.

[TomDrinkwater]

this look much better! I got 5ms latency at both 32 samples and at 256 samples.

I'll test more configurations soon and think about what the figure should be to be totally correct.

[TomDrinkwater]

I get quite a lot of error messages in console when changing the emu settings, and even just when the DAW is running but stopped. However when actually recording and playing back I don't see errors. However, my testing so far has been minimal.

same 5ms latency at both 88.2Khz and 44.2Khz

[TomDrinkwater]

I have insomnia, so I did more testing.

• the round trip latency now seems to be predictable.
• however it is consistently 5ms more than the reported latency.
• I looked into the reaper latency compensation, and turned it off for testing. The latency of the emu varies as expected with the plist latency setting and with the daw buffer size, except that there is always a fixed ~5ms more latency than reported.
• I cannot tell yet if the 5ms extra fixed latency is in the input or the output.
• I tried setting the plist to 1500uS and it seemed to work fine so far. The latency decreased by the amount expected (ie 1.4ms less round trip latency than 2200uS)
• I tested my fireface800 and alesis photon real latencies, and both are under-reporting their real latencies, the fireface is the best it under-reports by only ~1ms, the alesis under-reports by ~3ms.
• reaper allows you to manually set a compensation value for input and output latency - i will start doing this in future. However obviously it is better to get the reporting correct.
• with small buffer and plist safety buffer sizes I can now get real round trip latencies as low as 11ms, which is acceptable, although still higher than my other interfaces.
• goal: - obviously it would be good if we could discover the cause of the 5ms extra latency, and if it is input or output, and reduce or remove it if possible, and report it correctly regardless.

[Wouter1]

this look much better! I got 5ms latency at both 32 samples and at 256 samples.

Now that is excellent news! I'm glad that I could get this working correctly

This is roundtrip latency? with the 4.2ms or with 2.2ms latency setting?

[Wouter1]

Do I understand you correctly, the roundtrip latency you get is

with low latency setting 2 * 2.2 ms + 2 * 5ms extra = 14.4ms with normal latency setting 24.2 + 2 \ 5ms extra = 18.4ms

[Wouter1]

I get quite a lot of error messages in console when changing the emu settings, and even just when the DAW is running but stopped. However when actually recording and playing back I don't see errors. However, my testing so far has been minimal.

Yes at the moment of switching it's currently normal to see errors like this

Feb 20 08:37:12 --- last message repeated 127 times ---
Feb 20 08:37:12 vlieland kernel[0]: warning way-out ring wrap position
Feb 20 08:37:12 --- last message repeated 1 time ---
Feb 20 08:37:12 vlieland kernel[0]: frameSizeQueue empty, guessing some queue size. May need fix..
Feb 20 08:37:12 --- last message repeated 63 times ---
Feb 20 08:37:12 vlieland kernel[0]: warning way-out ring wrap position
Feb 20 08:37:12 --- last message repeated 2 times ---
Feb 20 08:37:12 vlieland kernel[0]: RingBufferDefault<USBInputRing>::push warning. Ignoring overrun
Feb 20 08:37:12 vlieland kernel[0]: warning way-out ring wrap position
Feb 20 08:37:12 --- last message repeated 3 times ---
Feb 20 08:37:12 vlieland kernel[0]: RingBufferDefault<USBInputRing>::push warning. Ignoring overrun
Feb 20 08:37:12 vlieland kernel[0]: warning way-out ring wrap position
Feb 20 08:37:13 --- last message repeated 3 times ---
Feb 20 08:37:13 vlieland kernel[0]: RingBufferDefault<USBInputRing>::push warning. Ignoring overrun
Feb 20 08:37:13 vlieland kernel[0]: warning way-out ring wrap position
Feb 20 08:37:13 --- last message repeated 3 times ---
Feb 20 08:37:13 vlieland kernel[0]: RingBufferDefault<USBInputRing>::push warning. Ignoring overrun
Feb 20 08:37:13 vlieland kernel[0]: warning way-out ring wrap position
Feb 20 08:37:13 --- last message repeated 3 times ---
Feb 20 08:37:13 vlieland kernel[0]: RingBufferDefault<USBInputRing>::push warning. Ignoring overrun
Feb 20 08:37:13 vlieland kernel[0]: LowPassFilter::filter init 128000000
Feb 20 08:37:13 vlieland kernel[0]: USB timer started
Feb 20 08:37:13 vlieland kernel[0]: RingBufferDefault<USBInputRing>::push warning. Ignoring overrun
Feb 20 08:37:13 vlieland kernel[0]: **** Output Hiccup!! firstSampleFrame=2344, nextExpectedOutputFrame=6936 bufsize=147456
Feb 20 08:37:13 vlieland kernel[0]: RingBufferDefault<USBInputRing>::push warning. Ignoring overrun

But not after the short init phase

However you continuously keep getting the push warning if you are playing sound but not recording.

[TomDrinkwater]

Do I understand you correctly, the roundtrip latency you get is

with low latency setting 2 * 2.2 ms + 2 * 5ms extra = 14.4ms with normal latency setting 24.2 + 2 \ 5ms extra = 18.4ms

No, the 5ms is roundtrip unaccounted for, not both in and out. I can't tell easily if it is input or output.

so the total roundtrip latency I get is:

(plist safety buffer * 2 ) + (daw buffer size * 2) + 5ms

that 5ms could be 2.5 input and 2.5 output, or 5ms input or any mixture, right now I cannot tell.

I will check more soon and see if it a specific numer of samples. for example the FF800 was under-reporting its latency by exactly 128 samples at 88k and 96k and 64 samples at 44k, I wonder if maybe this 5ms could be 256 samples as 44k and 512 at 88k? But I'm guessing.

[Wouter1]

I found this short article on the EMU driver latency.

http://www.soundonsound.com/sos/jan07/articles/emu0404.htm

... to reveal any 'hidden extras' in real-world audio latency. ... USB and Firewire interfaces often employ additional hardware buffers... I'm pleased to report that Emu have declared these extras accurately, so you know exactly what's what.

Keeping the total input latency fairly low is important when monitoring with plug-in effects, and the extra 1.878ms imposed by the 0404 USB is little more than that of most PCI and PCMCIA interfaces, while the rather higher 4.893ms added to the output latency seems fairly typical of USB and Firewire interfaces (the extra buffering ensures smooth playback).

I'm trying to find where EMU itself reports these values.

This might be exactly what we're looking for? If this is indeed a hardware latency, the only thing I can do is add them readily to the latency that the driver reports back to the software.

[TomDrinkwater]

it would certainly be useful to find where emu declares those values in its code. However I would think that the values given would be driver + hardware latency as one figure. I don't think a reviewer at SOS will be equipped to tell the difference. I think they are just talking about the total latency that isn't caused by the DAW buffer.

[Wouter1]

I have never seen these values in the OSX driver.

[Wouter1]

I checked the DA+AD combined performance at 192kHz. We have more clicking than acceptable. Might be input or output problem but something is not ok at this point.

[Wouter1]

However I would think that the values given would be driver + hardware latency as one figure

Yes I think a manufacturer should specify total latency. But the reviewer is talking exactly about that - that some manufacturers exclude the hardware latency from their numbers.

I will check what their original driver reports for latency. Maybe that's what he is talking about.

[TomDrinkwater]

I have not noticed any clicking but I have not tested at 192K. (I don't believe that there is any improvement in sound past 88k or so, so I never bother. I would gladly trade 192K performance for lower latency at 44 and 88k.) I will also check at 192k and see if I get clicks.

what did you do for your check?

could the reported latency values be specified in samples rather than ms, making them harder to recognise? or calculated on the fly from other variables so there are no actual numbers visible?

I think he means their original drivers reported latency matches the latency he measured.

[Wouter1]

original driver

rate (kHz)	reported latency (frames)	latency(ms)
44.1	90	2.04
48	98	2.04
88.2	178	2.02
96	194	2.02

This is exactly 2 times the frame size. And this matches the values I see in the original source code.

[TomDrinkwater]

I have no clicks recording or playing back at 192k as long as I allow sufficient buffer in the DAW for the DAW to do the extra processing for the high sample rate.

Also, at 192k I recorded some sound, then recorded it in a loop back test for latency.

the reported latency including the daw latency was 4.1/4.1ms (512 samples at 192Khz. The total round trip actual latency was only a little over 10ms. so the latency unaccounted for in this case is only about 2ms.

this is all with the plist buffer set very short to only 1500uS

[TomDrinkwater]

original driver |rate (kHz)|reported latency (frames)|latency(ms)| |44|90|2.04| |48|

is this code from the original driver? it doesn't seem to match that article...

[TomDrinkwater]

But the reviewer is talking exactly about that - that some manufacturers exclude the hardware latency from their numbers.

maybe this is what I am experiencing with my other interfaces. Fortunately reaper lets you enter a value to compensate for manually.

[Wouter1]

Correct, these are not the values as in the article. But the input latency is pretty close at 1.878 where we have 2ms. The output latency is however way off. Maybe it's different on windows?

[TomDrinkwater]

who knows? maybe whatever change in the OS broke the original driver changed the latency too?

[Wouter1]

this maybe what I am experiencing with my other interfaces. Fortunately reaper lets you enter a value to compensate for manually.

I tested my fireface800 and alesis photon real latencies, and both are under-reporting their real latencies, the fireface is the best it under-reports by only ~1ms, the alesis under-reports by ~3ms.

Yes if you measured the latency correctly, that's clear enough

[Wouter1]

maybe whatever change in the OS broke the original driver changed the latency too?

No I don't think so. The original EMU source code has these values - 2 times the frame size - exactly as we see them in the table.

[TomDrinkwater]

are the values in that table currently being reported? how do they relate to the value in the plist? are they hardware not driver values?

[Wouter1]

I checked the ADC (AK5385A) datasheet. It has a group delay of 43.2/fs. That makes almost 1ms at 44kHz and lower at higher samplerates.

The AK4396VF has a group delay of 28/fs. That makes 0.63ms at 44k

So this accounts for 1.5ms latency in the round trip.

[TomDrinkwater]

looks like there's still a factor missing, but knowing the DAC and ADC hardware latencies is good progress!

[TomDrinkwater]

I will test more when I get time to see how the extra latency changes. it seemed to be constant at 44.1khz, but maybe it is different at each rate.