Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

[Split from http://yabb.jriver.com/interact/index.php?topic=92593.0 by JimH]

I had a quick play with this earlier and it was definitely a fail with convolution on (using a minimum phase version of my usual filters) but seemed ok with convolution off. Do you have a good way to measure the actual latency in the chain?

My method isn't super accurate, it was just designed to give an order of magnitude on the software latency.  What I did was:

1) Took a measurement using Holm outputting directly to my soundcard with ASIO set to 64 samples, and noted the sample offset of the arriving signal.

2) Then setting JRiver to output using ASIO to the same device at 64 samples, I set the live playback buffer setting in JRiver very high (hundreds of milliseconds) and took a measurement using Holm through the WDM driver and noted the resulting sample offset (you might need to take two measurements back to back to make sure the driver is engaged).

The sample offset in 2) minus the offset in 1) (converted into milliseconds) was within a few milliseconds of the live playback buffer settings in JRiver.  After confirming that half of the equation, I tried repeating the experiment: step 1) was the same, but in step 2) I increased my ASIO buffer settings in JRiver and saw the appropriate increase in latency within a millisecond or two.  

That was the basis for my conclusion that the total software latency was more or less the sum of the two buffers.  Obviously that's only a good way to figure out what your software latency is, not your hardware latency. In my case the best evidence I can find suggests my "base" hardware latency is four or five milliseconds; you may be able to find similar measurements for your interface.  What are you using as a sound interface these days?

Measuring hardware latency is hard because it usually requires a loopback or microphone, and then you're unavoidably measuring the input latency as well as the output latency etc. There are tools that will do that, but it's hard to sort out what the latency of each stage actually is.  Most people just do a physical loopback measurement and half it which isn't always the best solution.

Mojave may have some ideas about this, I recall him getting some fairly precise hardware latency measurements at one point from soundonsound?

[mattkhan]

My method isn't super accurate, it was just designed to give an order of magnitude on the software latency.  

Mitchco suggested this tool on the acourate list - http://www.oblique-audio.com/free/rtlutility

It looks like it should do the job, I will give it a try later. At least it should tell me how long the filter itself is anyway.

The other thought I had is that jriver itself must know this value in order to maintain lipsync for things it plays itself. If so, could jriver expose this value somewhere?

[mwillems]

Mitchco suggested this tool on the acourate list - http://www.oblique-audio.com/free/rtlutility

It looks like it should do the job, I will give it a try later. At least it should tell me how long the filter itself is anyway.

The other thought I had is that jriver itself must know this value in order to maintain lipsync for things it plays itself. If so, could jriver expose this value somewhere?

I'll be interested in how that works out.  Do you know how that tool separates out the output and input latency?

[mattkhan]

I'll be interested in how that works out.  Do you know how that tool separates out the output and input latency?

I don't think it does, it just reports the round trip time. My thinking was to measure without convolution and then with and this will tell me the filter latency. I can then try a few different filters to see whether I am having a marked impact on latency or whether I just need to go peq only.

My hardware is an rme fireface 800, it has selectable buffer sizes but I find it gets glitchy if i go below 512 samples. It seems to automatically kick up to 1024 samples of I play anything high res.

[mwillems]

I don't think it does, it just reports the round trip time. My thinking was to measure without convolution and then with and this will tell me the filter latency. I can then try a few different filters to see whether I am having a marked impact on latency or whether I just need to go peq only.

My hardware is an rme fireface 800, it has selectable buffer sizes but I find it gets glitchy if i go below 512 samples. It seems to automatically kick up to 1024 samples of I play anything high res.

That makes sense; comparative latency is all that can be measured with relative certainty (as you can see from my method) 

[mattkhan]

That makes sense; comparative latency is all that can be measured with relative certainty (as you can see from my method) 

so the results are .... confusing

I probably need to come up with a more systematic test plan (and collect more samples as there is certainly some noise in the results) but so far it suggests the following initial results

- ASIO is an order of magnitude faster than WDM; the tightest ASIO RTT I can get is ~3.5ms with a 48 sample buffer (at higher buffer sizes, the reported RTT was pretty consistently about 2x the buffer, at low sample rates it was more variable between 2.5-3.5x), WDM is more like 35-40ms (and quite variable, I saw results upto 60-70ms while changing nothing)
- routing through JRiver vs direct ASIO vs RME WDM drivers; at the same RME buffer size (512 samples) and with everything in jriver dialled down to the minimum I get ~110ms (+/- 5ms) from both RME WDM and JRiver WDM vs an absolutely rock solid 24.717ms from ASIO
- adding convolution breaks it entirely as it takes longer than the app expects

The main thing I am unsure about in the above is whether the RME buffer size is on top of the WDM buffer so that I'm not comparing like with like when looking at ASIO vs WDM. I think this does support the contention that there is essentially no (or negligible) added latency from jriver here.

Note that jriver crashed twice in 15mins of doing this, or rather 1 hang then kill and 1 hard crash. Obviously this is not normal use but it does indicate there is something a bit flaky in here (no surprise there of course, it is a v first public release)

The main problem with using the tool is that it emits quite a brief pulse, too quick for the WDM driver to wake up for. I have found that also playing a low level (I used -50dBFS) sine wave is enough to keep WDM alive while still leaving sufficient SNR for it to measure as accurately as it can. Something akin to a network RTT tool would be ideal here; i.e. emit a series of pulses (000s), collect the RTT, report on the distribution.

I'll give the HI approach a try at some point though an easier life would just be to knock out some PEQ filters to get something rough in place be done with it!

[mwillems]

- ASIO is an order of magnitude faster than WDM; the tightest ASIO RTT I can get is ~3.5ms with a 48 sample buffer (at higher buffer sizes, the reported RTT was pretty consistently about 2x the buffer, at low sample rates it was more variable between 2.5-3.5x), WDM is more like 35-40ms (and quite variable, I saw results upto 60-70ms while changing nothing)
- routing through JRiver vs direct ASIO vs RME WDM drivers; at the same RME buffer size (512 samples) and with everything in jriver dialled down to the minimum I get ~110ms (+/- 5ms) from both RME WDM and JRiver WDM vs an absolutely rock solid 24.717ms from ASIO
- adding convolution breaks it entirely as it takes longer than the app expects

The main thing I am unsure about in the above is whether the RME buffer size is on top of the WDM buffer so that I'm not comparing like with like when looking at ASIO vs WDM. I think this does support the contention that there is essentially no (or negligible) added latency from jriver here.

I don't think the 512 sample buffer is on top of the WDM latency (certainly that's not how I've observed the buffer settings to work in JRiver).  The sample setting is the ASIO buffer size, and has no effect on WASAPI playback (as far as I can tell); ASIO is just a much lower latency format than WDM, which I think you're seeing.  Glad to confirm that JRiver isn't a significant source of latency regardless.

The main problem with using the tool is that it emits quite a brief pulse, too quick for the WDM driver to wake up for. I have found that also playing a low level (I used -50dBFS) sine wave is enough to keep WDM alive while still leaving sufficient SNR for it to measure as accurately as it can. Something akin to a network RTT tool would be ideal here; i.e. emit a series of pulses (000s), collect the RTT, report on the distribution.

I'll give the HI approach a try at some point though

The nice thing about holm is that you can specify a long enough sweep that it will cope with the WDM startup time.

an easier life would just be to knock out some PEQ filters to get something rough in place be done with it!

Yes, that was the conclusion I came to a very long time ago when I started using loopback.  Others have had good luck making very short convolution filters though.  You could probably sort out something rough and ready by starting with a very low number of taps and gradually increasing (e.g. good old trial and error).