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.

[Wouter1]

I wonder though do I need to leave it for 1-2mins to stabilise after changing the rate before testing?

Can you select the rate with the control panel, so that you do not have to switch rate in reaper? And yes please check for say 5 minutes, this might be a clock issue.

[Wouter1]

08/03/2015 17:04:15.000 kernel[0]: frameSizeQueue empty, guessing some queue size. May need fix..

Should happen only during first second after start

[Wouter1]

Tom, it seems that the internal latencies as we measured them before are changed now.
Could you please have a look at issue #53 and provide me with updated measurement results? Then I can fit these values into the driver for the Tracker Pre as well.

[TomDrinkwater]

i did some more tests at 88k and 96k. after rebooting. clicks maybe 15 times in 10 mins at 64 samples, only one or 2 clicks in 10 mins with daw buffer 128 samples, which is the same latency as 64 samples at 1x rates.

the clicks are different to how they were before they are no longer exactly one daw buffer long. so the cause must be different.

I will measure in a different way when I can and get the latency figures. so far the latencies seem to be about the same as you are getting, but i will check more accurately with a signal that contains a sharp transient.

also I can't find any error message in console at the time the click occurred.

[TomDrinkwater]

the clicks have no relation to the start, they happen randomly throughout and sometimes not in the first minute.

[TomDrinkwater]

i will test in a different way tomorrow or tuesday in case the clicks i have are not the driver at all but something else.

[Wouter1]

Thanks Tom! It's strange that the number of clicks depends so extreme on the buffer size. Maybe a CPU load problem? How much load do you have?

We may have to run a clock test (as the graphs above) on your machine.

[Wouter1]

Tom did you already figure out if this is a driver issue or something else?
Do you have the EMU directly attached to the compu or is there a hub in between?

As said, if the clicking persists I propose that we do a clock test. I can prepare a test driver for you to measure that

[TomDrinkwater]

Hi, I haven't had time to test more, but maybe i can do some tonight. I will try without the hub again (it made no difference with an earlier driver) and also a different computer.

[Wouter1]

Would be great if you can try that.

Notice that I fixed the reported latency in #53 and released a new version for the kext for that. v3.5.2. I hope you like it!

[TomDrinkwater]

cpu is at about 20% on all 4 cores when running the test, it is an old computer. In activity monitor i see high levels of wakeups from kernel_task and from coreaudiod when reaper is running, presumably this is the fast polling on the driver.

however when i boot another app while the test is running and cpu goes up for a few seconds as a result it does not cause a glitch.

here's a pic of a typical new type glitch (total length about 520 samples at 88k)

and here's an activity monitor screenshot

i will test on another computer. Do i need to download the new version or is the reporting the only difference?

[TomDrinkwater]

today's test are without hub, and unplugged all unnecessary usb devices, seems to make no difference.

[TomDrinkwater]

note the new type glitch has a piece of misplaced audio, and also some flatline - that is typical - the flatline is new. the exact length now varies, and it seems unrelated to daw buffer size, wheras the old glitch was always one daw buffer exactly.

[TomDrinkwater]

so i should test the version that say 3.5.2 not the version that says test which still says 3.4.0?

[TomDrinkwater]

glitches at 88k 64 samples daw buffer seem to always be the same length 526 samples and at 96k 552 samples. give or take a few samples for my measuring accuracy. so glitch length s related to daw buffer size.

however the proportion of misplaced audio and flatline in the glitch is not constant.

[Wouter1]

Thanks Tom for all the testing. The CPU load should quickly drop if you increase the reaper buffer size. Can you confirm that?

About that clicking, is that only happening if you start an application while sampling? I have seen some apps that hog all the CPU available and then we can't avoid glitches.

About that version number , Something went wrong with the plist it seems, XCode apparently did not commit/push it. The versions tagged 3.5.1 and higher are both fine for testing.

[TomDrinkwater]

About that clicking, is that only happening if you start an application while sampling? I have seen some apps that hog all the CPU available and then we can't avoid glitches.

No, in fact i tested that and it clicked when there was no extra cpu load and didn't click when I launched other apps, with cpu load rising briefly to 60-80% but the extra cpu did not cause a click.

I have seen no version numbers between 3.4 and 3.5.2 - I will test the current driver 3.5.2 unless you tell me otherwise. Can I ignore the one marked test now?

I will confirm about buffer size and cpu usage today, and maybe get on to trying another computer, but i'm not sure.

[Wouter1]

Can I ignore the one marked test now

Yes. The driver with double rate is now the official main version.

Therefore the clicking is the main issue.

I made a new ticket for this #55. I propose that we continue working there since this ticket is getting too large.

I think we should close this ticket. On your machine the latency is now as expected ?

[TomDrinkwater]

I will test latency soon and see if it is the same as the new reported latencies - I'll report here.

[TomDrinkwater]

ok latency test results:

these are all with 1ms in the plist

assuming reaper is correct the driver is now over-reporting its latency.

rate	daw buffer	latency in samples	in ms	roundtrip -daw	difference when using compensation in reaper
44	128	496	11.2472	5.442	-12
48	128	409	8.5208	3.188	-113
88	128	666	7.5510	4.649	-4
96	128	682	7.1042	4.438	-18

[TomDrinkwater]

so the performance is good, better than your reporting formula, and especially and anomalously (suspiciously?) good at 48k!

Of course we would expect that these figures would be slightly different for the different hardware because of different converter latencies, and also it will never be sample accurate because it is going through analogue.

However it looks like the latency reporting formula needs some adjustment, especially at 48k.

At 88k it is as close to correct as I would ever expect.

[TomDrinkwater]

to clarify the above: - the negative numbers in the last column show the number of samples AHEAD of the original the loopback signal appears in reaper when using reapers compensation set to "use driver reported latency".

[Wouter1]

Thanks Tom for the new measurements. I will update the table in #53 accordingly

[Wouter1]

Tom, that measurement at 48k seems odd, the latency seems VERY low at 1.19ms where I expect ~3.5ms. Also it is not in line with the other results. Can you re-measure that?

[Wouter1]

BTW let's continue the latency checks further on #53. I think the latency issue is basically fixed (except for the clicking #55 ), and #53 is about now reporting the correct latency to Core Audio.