Print

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

[mattkhan]

I think I am slowly going crazy here....

I have a 5.1 setup and bake delays into the filters, the filters are generated by Acourate and it doing this involves a slightly laborious manual process to rejig some of the generated filters. I have a well worn process for this but obviously it's manual and manual processes are error prone. Nevertheless recently, where recently is the last few months, it seems to produce some broken (0s of ms per channel offset) delays when I verify the actual measurements using the asio line in/rew loopback combo. This is not just a measurement problem as I only actually noticed it once I listened to some multichannel music (and even then only some particular tracks but then those tracks were obviously wrong). Interestingly, or not, I have not noticed this at all during films (random aside, the things wrong with an audio setup that I have learnt I don't notice until I do notice them is alarmingly long since I bought jriver and started convolving!).

I am as confident as I can be that rew/asio line in is not the source of these days as I have cross checked this every which way but loose. It is absolutely stable and consistent with respect to timing.

This leaves the filters. I have double checked and cross referenced my filters n times now (where n is at least 3, it's quite time consuming!) and I can't see a problem. I am part posting this on the basis that as soon as I write/talk about this, I will see the error of my ways (it works when programming) but also because I have a genuine q behind this.... is there any way to execute a filter and verify the delay incurred per channel? If I could do this then I could empirically verify the filter delay. Does some other piece of software expose this info for example? I can do this on linux or windows if that helps (linux tends to bury you with data about anything like this hence why I mention it).

Any other ideas/suggestions welcome too.

[mattkhan]

One idea I had was to verify the convolution independently by creating a multichannel wav of dirac pulses and then running that through my convolution filter (using http://convolver.sourceforge.net/convolvercmd.html), I could then look at the result to see whether the delays are as expected. If this works correctly then the problem can't be in my filters.

Current stumbling block, working out how to create a multichannel wav (currently trying audacity but a seemingly obvious thing is not obvious).

[mattkhan]

OK so this looks correct to me, attached pic is results of running a set of dirac pulses through a filter with the result that they now look like the correct delays are in place.

I think the next step would be to play that through jriver and then capture the output in the same way. This seems possible using audacity capturing 2 channels at a time and rerouting the channels according in my mixer.

[mattkhan]

I measured the different sets of filters directly as played by jriver and it still all looks good, the L channel in each track is the L speaker and the R channel in track is R C SL SR respectively. Each of my 3 filter sets are completely consistent with respect to timings.

[mattkhan]

I'm completely confused now as those filters all look correct. Nevertheless 2 of those 3 filters sound completely wrong when actually listening to them in certain sections of music, it sounds like the beat is off (e.g. a set of drums that was coming out of multiple speakers sounded really discordant). The REW loopback measurements (another pic attached showing impulses far apart) I took yesterday corroborate this idea as they should this sort of view where each impulse is clearly way off target. As far as I could tell, this was repeatable so I can't see how it can be a measurement error  ?

[mwillems]

Matt,

I'd like to help but I'm a little confused about the differences between your testing methodologies, specifically the signal chains.  How are you capturing JRiver's output in Audacity vs. REW (you describe using a REW loopback?)?  Is one pure software loopback and the other hardware loopback?  Or is one software loopback and the other is open air measurement?  Or something else?  If you could maybe lay out the differential signal chains in the two tests we can try to isolate what's happening a little better.

As I understand it you're somehow directly capturing JRiver's output of a convolved impulse in Audacity and getting "correct" results, but I'm a little foggier on how the signal is getting into REW.  Cable loopback?  Microphone?  Something else?

[mattkhan]

Thanks for trying to help! I've been trying to build it up one step at a time to see if I can isolate where the problem creeps in.

To that end, the signal chains were as described below. One thing to note is that I use an RME FireFace 800 which exposes a WDM driver for each pair of inputs and outputs, TotalMix FX then gives you the usual sort of mixer functionality including marking each output as a loopback so it appears back on the same input.

1) offline convolution
no signal chain as such, just an offline convolution in order to directly verify that the filter itself is correct (as a sanity check more than anything)

2) online convolution through jriver
audacity is set to record on inputs 1 & 2
jriver is set to output format of 5.1 & convolution is active
the test file is a 6 channel wav with each channel containing a 1 sample long dirac pulse at the same point (i.e. all channels are identical)
using totalmixfx, output channel 1 is always playing the L channel only and I change channel 2 so it is playing one of the R/C/SL/SR channel each time I play the track

3) at the listening position
REW is set to output on asio channel 7 on the RME
jriver asio line in is opened to listen to channels 7 and 8 from the RME
jriver output format is 5.1 & convolution is active
REW input is set to the mic
REW timing reference input is set to one of 1st 6 channels, i.e. it is listening to the convolved signal (if you don't do this then REW gets confused because of the large delay between the actual signal and the timing signal)
I measure a single channel at a time by rerouting the output in totalmix

Having written this down I realise there is at least one more layer I haven't measured as a potential source of variable latency & that's using asio line in. However this has been completely stable in the past (albeit I've never measured this as far as I remember on jriver 20).

I think that covers it but ask away if something isn't clear

Cheers
Matt

[mattkhan]

Writing this down made me think of a few other possibilities

1) was I inconsistent with the processing applied to the timing signal? e.g. I used C on 1 measurement, SL on another (i.e. filters with different delays baked in)
2) is the processing applied to the timing signal confusing REW in some way?

I guess I need to take a few more measurements to verify.

[mwillems]

Writing this down made me think of a few other possibilities

1) was I inconsistent with the processing applied to the timing signal? e.g. I used C on 1 measurement, SL on another (i.e. filters with different delays baked in)
2) is the processing applied to the timing signal confusing REW in some way?

I guess I need to take a few more measurements to verify.

You've read my mind, although if you can hear clear errors then it's not just a measurement artifact right?  You would hear 70ms of mistiming (it would sound like an echo).  I'm still wondering if something downstream of JRiver is actually introducing that delay somehow.  But it can't be time of flight or cable runs, because your speakers would need to be 70ft apart or you'd need 100's of ft of cable.  So something in the output stage may be introducing interchannel delay?  Are you running all your speakers from the same amp?  Same signal path coming out of the DAC?

Also, I know this isn't your preferred solution, but have you tried adding interchannel delay in a less labor-intensive way for testing purposes (either in the convolution config file or in PEQ in JRiver)?

A test: what happens if you try and "fix" the delay you're seeing in REW with JRiver's delay filter in PEQ after convolution?  Get it to where REW measures correctly and then listen.  Try and find some program material that would exhibit the problem well, etc.

[mattkhan]

I have a single power amp for the mains and one for the sub, all the kit is in the same rack and there is one DAC (the RME).

A test: what happens if you try and "fix" the delay you're seeing in REW with JRiver's delay filter in PEQ after convolution?  Get it to where REW measures correctly and then listen.  Try and find some program material that would exhibit the problem well, etc.

I will measure again first and then give that a try.

[Mitchco]

3) at the listening position
REW is set to output on asio channel 7 on the RME
jriver asio line in is opened to listen to channels 7 and 8 from the RME
jriver output format is 5.1 & convolution is active
REW input is set to the mic
REW timing reference input is set to one of 1st 6 channels, i.e. it is listening to the convolved signal (if you don't do this then REW gets confused because of the large delay between the actual signal and the timing signal)
I measure a single channel at a time by rerouting the output in totalmix

Cheers
Matt

Matt, this is very similar to how I measure my 3 way active stereo setup.  I also use JRiver 5.1 output format and the delays for each driver (for time alignment) is baked into the filters.  The only difference is that I do not use REW's timing reference...  I have not had a problem with REW being confused by the signal delay...  I am using Hilo's multi-client ASIO driver and the routing is performed in the Lynx Hilo's firmware...  Are you using the RME ASIO driver for REW?

Not that it helps you any Just saying what's different. So many variables, hard to isolate.  Might want to verify that you get consistent RTL Utility timings with the RME device (in loopback mode) to take that out of the equation.

I don't know about HolmImpulse, but might want to try that in place of REW to factor the measurement software out of the equation as well.  Actually, should also be able to use Acourate in place of REW as well...

Wish I could be more help.  Best, Mitch

[mattkhan]

Matt, this is very similar to how I measure my 3 way active stereo setup.  I also use JRiver 5.1 output format and the delays for each driver (for time alignment) is baked into the filters.  The only difference is that I do not use REW's timing reference...  I have not had a problem with REW being confused by the signal delay...  I am using Hilo's multi-client ASIO driver and the routing is performed in the Lynx Hilo's firmware...  Are you using the RME ASIO driver for REW?

Not that it helps you any Just saying what's different. So many variables, hard to isolate.  Might want to verify that you get consistent RTL Utility timings with the RME device (in loopback mode) to take that out of the equation.

I don't know about HolmImpulse, but might want to try that in place of REW to factor the measurement software out of the equation as well.  Actually, should also be able to use Acourate in place of REW as well...

Wish I could be more help.  Best, Mitch

Hi Mitch

thanks for the comments, a few thoughts...

I find Holm good for some things, mainly creating filters for speclab as it can output in an fft bin friendly format, but for others not so good. In particular the I/O channel selection seems more limited so that it just never seems to work properly for me. Since I resolved the issues I had with the low end in REW (ultimately user error), I find it has all the features I need and is generally a better UI. Having said that, I realise I've been using REW since 2005 so perhaps I'm just used to it's way of doing things

The problem with using acourate here is that acourate is not my actual playback chain. I also find it's approach of coercing things to a logical point (sample 6000 IIRC?) rather than a physical point in time slightly obtuse for this use case.

I am using the latest RME drivers & I have the steinberg asio multiclient installed.

Re REW loopback and timing delay, I don't see how you are using REW to verify timing without using the "use loopback as timing reference" option (or whatever it is called). Can you share your exact setup (mixer settings, rew prefs etc) for such measurements? Now I think about it, I wonder if problem I refer to was when I was sending an actual timing reference output from REW? I stopped doing that once JohnM said REW doesn't it, it just looks for the input (presumably effectively assuming the output was sent when the actual output was sent).

A PC based audio setup is a magical mystery tour at times

[mattkhan]

JohnM replied to my Q on HTS - http://www.hometheatershack.com/forums/rew-forum/98929-how-tolerant-rew-processing-applied-timing-reference-signal.html#post974313

This indicates my signal chain is not what I think it is hence I will be back in a few days (must stand in cold field watching fireworks with kids tomorrow!) with more data.

[mattkhan]

OK so basically I may have been chasing ghosts in the machine  ?

I had a moment of clarity the other evening as I realised that I had a bad loopback setup which meant REW was seeing the input signal as the loopback. This explains the wildly varying times as the "time of flight" was including variable latency in the PC. I corrected this & remeasured and then realised my approach to using the mixer to route output to each channel was flawed (basically meant I was routing a convolved L channel to each physical speaker == fail). I then corrected this & found that all filters are absolutely correct and the initial impulses are within ~100us for each speaker when using any of my filters (which is within a sane margin of error for mic placement).

On the one hand, yay for not having mysteriously broken filters.
On the other hand, now I'm wondering what I was hearing when I compared filters with that multichannel music. Mind you I did change one thing along the way as I realised that my processor was only in direct not pure direct mode on the PC input (though I didn't think distances applied to 7.1 analogue in anyway) so perhaps it was just that.

The one good thing out of this is that I think I can now see a way to measure the relative latency of a filter, just by changing which signal REW sees on the loopback will give me the total RTT which I can then compare against the reference "no filter" latency.

One final question on that, it looks like the processing time of a 96kHz filter is markedly less than a 48kHz filter. Is that correct/expected? ISTR reading that the jriver convolution implementation was a partitioned solution which resulted in no variation in processing time by sample rate. I can't find a reference to that now though so perhaps I was making it up. FWIW it looked like ~350ms for a 96kHz filter & ~700ms for a 48kHz filter (with a set of 64k tap FIR filters), both of which would imply it's not partitioned at all. No practical impact to this, just curious really.

[mwillems]

One final question on that, it looks like the processing time of a 96kHz filter is markedly less than a 48kHz filter. Is that correct/expected? ISTR reading that the jriver convolution implementation was a partitioned solution which resulted in no variation in processing time by sample rate. I can't find a reference to that now though so perhaps I was making it up. FWIW it looked like ~350ms for a 96kHz filter & ~700ms for a 48kHz filter (with a set of 64k tap FIR filters), both of which would imply it's not partitioned at all. No practical impact to this, just curious really.

The rough rule of thumb is that each tap is basically half a sample in time.  That means the basic estimate formula for FIR filter delay (without fancy processing) is

Code: [Select]

(Taps/2) / Sampling rate
That means that with a fixed number of taps a higher sampling rate should show a lower latency (the tradeoff is that it takes more taps to do equivalent correction at higher sampling rates).  Based on the formula, I'd expect 64K taps at 48KHz to result in (32K/48K)= 666ms and the same 64 K taps at 96KHz to result in 333ms.  The formula is an estimate, but still pretty close to your measurements.  So I'd say all is as expected with the delays.

Glad to hear you got everything sorted out, but it is a mystery what you were hearing.  Hopefully that becomes clear in time (I've certainly had my share of audio mysteries   )

[mattkhan]

The rough rule of thumb is that each tap is basically half a sample in time.  That means the basic estimate formula for FIR filter delay (without fancy processing) is

Code: [Select]

(Taps/2) / Sampling rate
That means that with a fixed number of taps a higher sampling rate should show a lower latency (the tradeoff is that it takes more taps to do equivalent correction at higher sampling rates).  Based on the formula, I'd expect 64K taps at 48KHz to result in (32K/48K)= 666ms and the same 64 K taps at 96KHz to result in 333ms.  The formula is an estimate, but still pretty close to your measurements.  So I'd say all is as expected with the delays.

Sorry, I wasn't clear. I know that is the expected delay of a linear phase filter with n taps by I thought the jriver convolver was a partitioned convolver like http://www.ludd.luth.se/~torger/brutefir.html#bruteconv_3

I cannot find a post referencing this though so it must just have been wishful thinking. It seems like it would be a nice feature to combine with the wdm driver.

[mwillems]

Sorry, I wasn't clear. I know that is the expected delay of a linear phase filter with n taps by I thought the jriver convolver was a partitioned convolver like http://www.ludd.luth.se/~torger/brutefir.html#bruteconv_3

I cannot find a post referencing this though so it must just have been wishful thinking. It seems like it would be a nice feature to combine with the wdm driver.

Ah, I see;  if MC is partitioned, I'm not aware of it.  To the extent I've been able to observe the delays (using variations on your methodology described above, for which, thank you!), they seemed to correspond (rough order of magnitude) to the formula.