latency too high

[Wouter1]

There seems much more latency than expected.

[TomDrinkwater]

could the latency be different for the different hardware, more channels = different ADC+DAC?

[Wouter1]

Yes I just checked the 0204 manual and it has a entirely different DAC- a CS4396. The AD is the same

[Wouter1]

The 0204 (Cirrus logic) has a group delay of 11/Fs (quad speed) or 20/Fs (double speed) or 37/Fs (single speed). Worst case ( single speed, 44k) gives then 0.84ms hardware latency in the DAC. So entirely different converter but quite similar latency.

[TomDrinkwater]

interesting! I wonder how different the different DACs sound. I'm looking in the tracker pre manual. It has only 2 channels out. The manual says it is a CS4392 DAC. Presumably a 2 channel version of the CS4396?

I wonder if it has the same latency?

It says the ADC is AK5385.

Will it be possible to report the correct latency for each different model of hardware? I think so.

It also says 176.4k & 192k sample rates not supported on Macintosh but it is working fine at 192khz. Is that one thing you changed?

[Wouter1]

I checked a single-chip-usb-DAC solution here http://www.ti.com/lit/ds/symlink/pcm2707.pdf

They are caching 1ms in the chip.

Packets in USB are sent in 1ms chunks so caching 1ms seems to make sense.

USB will send the data each millisecond in a burst. So I think the minimum cache for the DAC is 1ms.

For the ADC the same - they need a full buffer before they can start sending.

[Wouter1]

It also says 176.4k & 192k sample rates not supported on Macintosh but it is working fine at 192khz. Is that one thing you changed?

Yes I added support for 176.4 and 192kHz on OSX.

[TomDrinkwater]

I noticed it says in the manual that the zero latency monitoring is disables at 192k and 176k. I found that was true when I tested at 192k. Do you know why this is?

I would have assumed the the zero latency monitoring was purely analog, so the sample rate should make no difference. If it is after the ADC it wouldn't be zero latency!

I don't actually care personally, since I don't use those sample rates anyway, but it seems odd.

[TomDrinkwater]

Packets in USB are sent in 1ms chunks so caching 1ms seems to make sense.

USB will send the data each millisecond in a burst. So I think the minimum cache for the DAC is 1ms.

For the ADC the same - they need a full buffer before they can start sending.

I agree 1ms is the minimum possible usb io latency unless you write your own usb hardware driver or something like that.

I'm not sure if we have to have two such 1ms buffers though, one at the hardware end and one at the driver end? If so that would seem to contradict some of my results...

[TomDrinkwater]

if you need just over 1ms at each end of the usb cable in each direction, that would explain the 5ms I saw at 44k. But it wouldn't explain why I only saw 2ms at 192k.

[TomDrinkwater]

but where does the driver latency in the plist fit in? is there an additional latency in the driver we haven't found yet or not?

[Wouter1]

I'm not sure if we have to have two such 1ms buffers though, one at the hardware end and one at the driver end? If so that would seem to contradict some of my results...

The DAC needs a continuous stream of data while the USB data transport goes in bursts each 1ms. So the DAC needs a buffer I think

The ADC delivers continuous data and it is pushed onto USB into bursts. So again a buffer is necessary. Both buffers at least 1ms of data.

[Wouter1]

if you need just over 1ms at each end of the usb cable in each direction, that would explain the 5ms I saw at 44k. But it wouldn't explain why I only saw 2ms at 192k.

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.

2ms roundtrip extra latency

Yes at 192kHz the system may switch to a double-rate mode where a data burst is sent every 0.5ms instead of every 1ms. (I'm simplifying, there exist more USB modes but this is the only other mode used by EMU 0404).

Then we would need only a 0.5ms buffer.

Additionally, the DAC and ADC latencies will also be lower at the higher rates. It might all add up. We need to check all the details like at what rate which USB mode is used and what the DAC/ACC latencies are

[Wouter1]

BTW because of this extra mode OSX did not support these high rates I think.

[Wouter1]

normal latency setting in driver, assuming EMU0404

For interface/Alt we check this line in the syslog when switching the rate Feb 20 21:15:52 vlieland kernel[0]: ++about to set input : ourInterfaceNumber = 2 & newAlternateSettingID = 11

The settings particluarly poll Interval can be found in issue #10

All times in milliseconds

The "total extra roundtrip" is only the extra latency , not including the driver buffer latency.

The total roundtrip is including the driver buffer latency (4.2ms * 2 assumed for EMU0404).

These numbers are NOT including the DAW (application) buffer size.

rate	Alt	USB frame every	AD latency AK5385 ( 43.2/fs)	DA latency AK4396VF ( 28/fs)	total extra roundtrip (2xusb)	total roundtrip
44k	11	1.0	0.98	0.63	3.61	12.01
48k	13	1.0	0.9	0.58	3.48	11.88
88k	5	1.0	0.49	0.32	2.81	11.21
96k	7	1.0	0.45	0.29	2.74	11.14
176k	9	0.5	0.24	0.16	1.4	9.8
192k	10	0.5	0.23	0.15	1.38	9.78

[Wouter1]

Tom, does this fit with your measurements?

[Wouter1]

I noticed it says in the manual that the zero latency monitoring is disables at 192k and 176k. I found that was true when I tested at 192k. Do you know why this is? I would have assumed the the zero latency monitoring was purely analog, so the sample rate should make no difference. If it is after the ADC it wouldn't be zero latency!

Have a look at my diagram in doc/diagram.graphml

You can see that the directmonitor path is actually in the digital pathway. So it's not actually ZERO latency but has the AD and DA latencies at least. Also channels have to be mixed. My guess is that there is insufficient compute power to do these mix operations at 192k

[Wouter1]

I found that I had audacity latency set to 1ms. That may have been the cause of the clicks. With setting at 10ms the first test at 192k looks ok. Made new ticket for a full check of this new setup #42.

[TomDrinkwater]

Tom, does this fit with your measurements?

It seems consistent with my measurements, from memory. To be sure I would have to re-check more precisely, I don't think I can do that tonight. But soon.

[TomDrinkwater]

You can see that the directmonitor path is actually in the digital pathway. So it's not actually ZERO latency but has the AD and DA latencies at least. Also channels have to be mixed. My guess is that there is insufficient compute power to do these mix operations at 192k

Interesting. I will compare with what the fireface does at some point. I find even very small monitoring latencies are distracting when tracking because of phase cancellation - the best way is to monitor in analog before it gets to the ADC.

[TomDrinkwater]

Yes at 192kHz the system may switch to a double-rate mode where a data burst is sent every 0.5ms instead of every 1ms. (I'm simplifying, there exist more USB modes but this is the only other mode used by EMU 0404).

would it be possible to give the user control of when this double rate mode is used? such as a parameter in the plist? I'll explain more fully soon.

[TomDrinkwater]

what I mean is can the 0.5ms mode be used with a 44.1khz sample rate?

[TomDrinkwater]

hmm, the tracker pre uses different ADC and DAC to the above table, we might reasonably expect the figures to be a little different... so I will try to get accurate figures for you.

[TomDrinkwater]

here's some stuff about how the driver might be used, which I hope can inform our discussion of how it should be done.

The user currently changes sample rate and DAW buffer size through the daw.

I think it would be great to also allow the user to change the following parameters:

• Driver latency (currently adjustable via plist)
• USB mode 1ms or 0.5ms

there are 4 use cases I think we need to consider:

1. listening back to music in the highest possible quality requirements: * high sample rate * match sample rate to original file (ie no conversion) * stable with no glitches * latency is not important in this case
2. tracking overdubs while monitoring in analog or low latency output. requirements: * accurate reporting of roundtrip latency so new tracks line up with old tracks
3. tracking overdubs while monitoring through the DAW (most pros avoid this!) requirements: * low input latency so monitoring is not distracting * accurate reporting of both input and output latency
4. playing a virtual instrument live from midi in (the midi may not be coming in on the emu at all) requirements: * very low output latency * latency reporting not important since it can’t be compensated for anyway in this situation. * low midi input latency and very low midi jitter * cpu at a premium , and sound quality less critical, so probably use lower sample rates. 44 or 48k. * need cpu power for plugin instruments so need DAW buffer not too small, so even more important to reduce driver and USB latency * but oops DAC and USB latency are highest at low sample rates!

[Wouter1]

what did you do for your check? the test procedure as described in #36.

[Wouter1]

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

It's the reported latencies by the original driver

[Wouter1]

can the 0.5ms mode be used with a 44.1khz sample rate?

Yes. We may be able to use that to lower the latency

[Wouter1]

hmm, the tracker pre uses different ADC and DAC to the above table, we might reasonably expect the figures to be a little different... so I will try to get accurate figures for you.

Yes we need to check that. Will do that tomorrow.

[Wouter1]

there are 4 use cases I think we need to consider:

But while the latency is ok for USB, the EMU USB is not the greatest when it comes to low latency, right? Are the pros that need low latency even considering these EMU USB?

[Wouter1]

I think it would be great to also allow the user to change the following parameters:

Driver latency (currently adjustable via plist)

USB mode 1ms or 0.5ms

We do not have source code of the control panel. So currently the only way to adjust things is by editing the plist ... We would have to write a new control panel? Or what are you thinking?

[TomDrinkwater]

OK i tested each sample rate

all tests 256 samples daw buffer 1500uS driver latency

Rate	reported latency incl 256 sample daw buffer	extra roundtrip time in samples	extra in ms
192k	2.8/2.8	400	2.08ms
176k	2.9/2.9	404	2.29ms
96k	4.1/4.1	423	4.4ms
88k	4.3/4.3	427	4.84ms
48k	6.8/6.8	248	5.16ms
44k	7.3/7.3	251	5.69ms

times in ms are just calculated from the number of samples and the sample rate

the number of samples is fairly accurate, but might be one or 2 samples out.

the "extra" does not include the daw buffer or the reported driver buffer, it is just the roundtrip unaccounted for extra latency

[TomDrinkwater]

We do not have source code of the control panel. So currently the only way to adjust things is by editing the plist ... We would have to write a new control panel? Or what are you thinking?

I was thinking putting it in the plist would be a good start, and probably easy.

Then with the control panel it depends what hooks into the driver there are and how it works, it is pretty easy to write a tiny app with a few pulldown menus of options, but I don't know how it would talk to the driver. Do you know how the existing one works?

Certainly it would be great to be able to change them and reinitialise the driver without having to actually quit the daw and reload the kext.

[TomDrinkwater]

But while the latency is ok for USB, the EMU USB is not the greatest when it comes to low latency, right? Are the pros that need low latency even considering these EMU USB?

i'll have to check how it compares to the real latency (rather than reported) of other USB interfaces.

because it is inexpensive and has a good quality DAC I think many pros are attracted to it as a second or third interface not for their main studio. For example I am using it in my bedroom studio where I do synth sound design and composing, but I use the FF800 in my bigger room for serious recording. I might use the EMU for live synth performance if the output latency is good.

Of course the very few people who make good money from music can afford to have multiple expensive interfaces, but there are many serious but poor musicians out there too.

[Wouter1]

Thanks for the accurate measurements!

Looking at the figures, the most straightforwared explanation seems that there is one more cache in the system somewhere of 1 frame.

A few places come in mind

• In the OS, maybe it copies the data into some cache 1ms before the actual transfer
• In the EMU, maybe it has a 2 frames buffer, or a 1 frame buffer on the input but 3 frames on the output (the latter would match the unbalanced figure from that SOS article)

[Wouter1]

Added the tracker pre manual to doc/

The tracker pre uses the CS4392 instead of the CS4396 . Dished up the datasheet and put that in doc too

[Wouter1]

The latency of the CS4392 apparently depends on 3 factors: the speed mode (single, double, quad), the sample frequency, and the roll off speed. The roll off speed probably is "high" as the "slow" speed is available only in control port mode, it seems that mode is for testing only.

The double and quad speed have a group delay of 4.6 resp 4.7/Fs. Only the quad speed mode supports rates above 100kHz so if the tracker pre uses a single mode, the mode must be the quad speed mode.

So let's take the 4.7/Fs as most likely group delay.

[Wouter1]

Here the table for the tracker Pre. normal latency setting in driver

For interface/Alt we check this line in the syslog when switching the rate Feb 20 21:15:52 vlieland kernel[0]: ++about to set input : ourInterfaceNumber = 2 & newAlternateSettingID = 11

The settings particluarly poll Interval can be found in issue #10

All times in milliseconds

The "total extra roundtrip" is only the extra latency , not including the driver buffer latency.

The total roundtrip is including the driver buffer latency (4.2ms * 2 assumed for EMU0404).

These numbers are NOT including the DAW (application) buffer size.

rate	Alt	USB frame every	AD latency AK5385 ( 43.2/fs)	DA latency CS4392 ( 4.7/fs)	total extra roundtrip (ad+da+2xusb)	total roundtrip
44k	11	1.0	0.98	0.11	3.09	11.49
48k	13	1.0	0.9	0.10	3.0	11.4
88k	5	1.0	0.49	0.05	2.54	10.94
96k	7	1.0	0.45	0.05	2.50	10.9
176k	9	0.5	0.24	0.03	1.27	9.67
192k	10	0.5	0.23	0.02	1.25	9.65

[TomDrinkwater]

those are good small DA figures.

with small driver latency and double speed USB we could get very good overall latency.

I have been using 1500uS driver latency with no problems so far. I hope soon I will do some actual music using the emu and that will give a longer test.

can you give me a clue how the control panel communicates with the driver? I am wondering about writing a control panel to display some of this info and let the user set usb rate and driver latency.

what else should be in a control panel?

[TomDrinkwater]

the current control panel for tracker pre is pointless because the only thing you can set is sample rate and you need to do that from the DAW anyway. I guess if the daw does not tell the emu then you would need it, but reaper seems to communicate the sample rate to the emu fine.

[Wouter1]

Analog filters in the EMU also add to the delays. I saw one datasheet recomending a 2nd order butterworth.

I can't find a simple calcutor for computing the actual delay of such filter. My guess is that 2nd order gives a delay in the order of the cutoff frequency. A simplistic 20kHz filter would then give a delay in the order of 1/20k = 0.05ms

[Wouter1]

the current control panel for tracker pre is pointless because the only thing you can set is sample rate and you need to do that from the DAW anyway. I guess if the daw does not tell the emu then you would need it, but reaper seems to communicate the sample rate to the emu fine.

Are you sure that the HARDWARE sample rate changes if you change the rate in the DAW? (eg, check the logs in the console or double check with the control panel).

[Wouter1]

Then with the control panel it depends what hooks into the driver there are and how it works, it is pretty easy to write a tiny app with a few pulldown menus of options, but I don't know how it would talk to the driver. Do you know how the existing one works?

I saw a little bit of it.

[Wouter1]

can you give me a clue how the control panel communicates with the driver? I am wondering about writing a control panel to display some of this info and let the user set usb rate and driver latency.

You need to check up the IOAudioControl class. The driver can announce these to the system. It can get callbacks when some values in there change.

I don't know how these objects are found from the client (the control panel).

[TomDrinkwater]

Are you sure that the HARDWARE sample rate changes if you change the rate in the DAW? (eg, check the logs in the console or double check with the control panel).

yes,, it changes in the control panel when I change it in reaper. Also if the hardware wasn't changing sample rate none of the testing I just did would make any sense, i think I would have noticed something wrong.

With some other DAWs though you do have to change the hardware separately.

[TomDrinkwater]

I don't know how these objects are found from the client (the control panel).

that is what was worrying me... so emu never open-sourced the control panel?

[TomDrinkwater]

Analog filters in the EMU also add to the delays. I saw one datasheet recomending a 2nd order butterworth.

since the filter is required by the DAC to prevent aliasing i would hope that it's latency would be included in the DAC latency, but maybe not if it is not on-chip.

[TomDrinkwater]

Looking at the figures, the most straightforwared explanation seems that there is one more cache in the system somewhere of 1 frame.

When I get time, I will test some more. There are a few things I am relying on being correct (eg that reaper applies the stated compensation accurately, and that the extra latency is not affected by DAW buffer size) which should be checked. Also maybe I should check on another computer.

[Wouter1]

yes,, it changes in the control panel when I change it in reaper. Also if the hardware wasn't changing sample rate non of the testing I just did would make any sense, i think I would have noticed something wrong.

If you change the project rte in audacity, nothing happens at hardware level. It's just CodeAudio upsampling the data

that is what was worrying me... so emu never open-sourced the control panel?

I have never found the source of the control panel.

But at this point I would not spend time on this. The gain to get via this is IMHO marginal. Better just switch to a higher sampling rate.

since the filter is required by the DAC to prevent aliasing i would hope that it's latency would be included in the DAC latency, but maybe not if it is not on-chip.

With that dac they recommand that extra filter, it's not on the chip.

[TomDrinkwater]

But at this point I would not spend time on this. The gain to get via this is IMHO marginal. Better just switch to a higher sampling rate.

if the settings are available in the plist that would be great, and enough for me.

switching to a higher sampling rate if you are using a virtual instrument such as a synth plugin uses much more cpu and often requires that the DAW buffer is increased. So then you lose more than you gain. So low latency at 44 and 48k is important in this case.

Yes the improvement is small. But there are so many layers of software on modern computers, and the general wider problem is that at each level the devs think that an an error or latency or whatever is in an acceptable range, but they all add up.

[Wouter1]

When testing the phase I noticed that the analogue input lags 148 samples behind the S/PDIF signal. This is when I connect both SPDIF and line out of the DAT output to the inputs of the EMU. rate=44kHz

148 samples = 3.36 ms

But it's hard to interpret this as we don't know if the DAT outputs are in sync, if this is even possible to say for an S/PDIF signal (it may have no exact timing data on the signal).

[TomDrinkwater]

I'm doing a much more complete roundtrip latency test.

so far 92k sample rate seems to be giving anomalous results. (unless it is my error)

can I email you a spreadsheet of results? is .ods libreoffice format OK or shall I convert to something else?