Print

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

[mattkhan]

This is a continuation of the discussion in http://yabb.jriver.com/interact/index.php?topic=95717.0 but phrased more explicitly to get dev attention & try to get a consolidated list of what is implemented. Ideally this would then be used to update the wiki (which I now see has been heavily revised in the last few days - http://wiki.jriver.com/index.php/Convolution)

The key features that I think need to be confirmed are;

• is it a partitioned implementation or not? if yes, when will it actually reduce latency? (both mwillems and I have measured the filter latency at text book linear filter length, some detail in http://yabb.jriver.com/interact/index.php?topic=93026.msg642528#msg642528)
• which features in the convolver cfg file are supported? everything except input weights + output weights + multiple output channels in a path + input line delays?

There was also a bug reported so there is a question over the nature of the filters supported

• does jriver support filters with inherent gain? see http://yabb.jriver.com/interact/index.php?topic=93578.msg646661#msg646661

Obviously I don't know if the above is a comprehensive list of the unknowns, these are just the issues I have experienced personally.

Background reading below.....

There are a few posts around that describe the feature list, I'll quote them here

• All processing is 64bit
• Any number of paths, targetting any input or output channel, is supported
• All FFT / iFFT evaluation is lazy so only run when necessary
• Filter files can be in any format supported by Media Center (.wav, .ape, .flac, .mp3, 16bit, 32bit, etc.)
• Partitioning is used to avoid latency (equal length partitioning for now, maybe unequal length someday)
• Latency is handled automatically so lip-sync for video works without additional user configuration
• Filters can be any sample rate (so one high sample rate, high precision filter can be used for all sources)
• Handles flushing nicely so the tail of the last song isn't heard when playing a new song
• Handles volume attenuation for clip protection automatically

Matt added this a few weeks later

Next build:
NEW: Added support for output delays in Convolution configuration files.

There are still a few unsupported features of Convolver configuration files.  I haven't seen them used, but just let me know if they're important to you:
Input line delays (different than output delays mentioned above)
Multiple output channels in a path (we support multiple input channels to one output channel, but not the other way around)
Output channel weights (this seems ambiguous / unnecessary since multiple paths can target an output channel, and you can set an input weight)

and

NEW: Convolution optionally searches for the best match configuration file based on the sample rate of the input and uses it if a better match is found.

We're supporting the formats like:
xxxx2.0_441
xxxx5.1_48
etc.

The regular expression is:
^(.+)(\\d{1}.\\d{1})_(\\d{2,3}).cfg$

Which outputs:
Name
Channels
Sample rate

Mojave summarised all this on HTS around the same time (http://www.hometheatershack.com/forums/rew-forum/54067-convolver-mic-phase-correction.html#post490005), the distinct information is below

Pink noise RMS output automatically normalized to -6 dB below input
Partition size will automatically adjust with the sample rate
Convolution uses SSE3 in the convolution kernel
Output channel weights
Bit perfect (limited testing by Uli Brüggemann of Acourate)

[glynor]

When you get it all sorted out, it'd be a good idea to add most of these technical details to the Convolution wiki article.

Perhaps in a Convolution Technical Details sub-page, so the main page remains "function first".

[mwillems]

When you get it all sorted out, it'd be a good idea to add most of these technical details to the Convolution wiki article.

Perhaps in a Convolution Technical Details sub-page, so the main page remains "function first".

Glynor, I'll get it integrated once we get everything sorted out.  Mattkhan and I hit the limits of my personal knowledge concerning JRiver's convolution implementation in another thread and I suggested he start this thread so he could get some resolution on a few questions he had, and for my own selfish reasons (to round out the wiki page ).  I'll probably add a "features" sub-category to the main page, and then build a technical sub-page.

[glynor]

Great.  Thanks.

[mattkhan]

When you get it all sorted out, it'd be a good idea to add most of these technical details to the Convolution wiki article.

Perhaps in a Convolution Technical Details sub-page, so the main page remains "function first".

unfortunately I think the only way to close this out for certain is for a dev to comment, the alternative is that mwillems just writes in the wiki the behaviour we see on our systems (which may or may not be technically correct).

[mattkhan]

gentle bump for this

would be nice to get a yay or nay either way though, if jriver don't want to comment because then the features become "public api" and it's a non core activity (or whatever the reason) then so be it.

[Matt]

Could you rephrase the question in a way I can understand?  There's a lot of talk above and it's not clear what you're asking.

Thanks.

[mattkhan]

Could you rephrase the question in a way I can understand?  There's a lot of talk above and it's not clear what you're asking.

Thanks.

Thanks for replying. The key questions are;

1) can you confirm exactly which features exposed by the convolver.cfg file (http://convolver.sourceforge.net/config.html) are supported by jriver?
2) Is it a partitioned implementation or not?
3) if it is, what latency reduction can be expected? e.g. is a particular hardware configuration (core count) required to achieve a latency reduction?

There was also a pointer to a bug about filters with inherent gain apparently not working properly (http://yabb.jriver.com/interact/index.php?topic=93578.msg646661#msg646661)

[Matt]

2) Is it a partitioned implementation or not?
3) if it is, what latency reduction can be expected? e.g. is a particular hardware configuration (core count) required to achieve a latency reduction?

Honestly I don't even know what a partitioned implementation is.  And I wrote our convolution engine!

[mwillems]

Matt,

Some explanation: there is a list of JRiver's convolver features summarized in the first post.  Two of the features mentioned as being supported are 1) input channel weights and 2) partitioned implementation.

On 1) mattkhan and I haven't been able to get input channel weights working.  
On 2) Both mattkhan and I have measured latency for the convolver and the latency we measured seems consistent with an unpartioned implementation.  We both measured delay equal to ((filter taps/2)/samplerate).  That's the delay that one would expect with an unpartitioned implementation.  

The questions are:  
1) Is channel weighting/scaling in config files supported (whether input or output)?
2) Is the convolution implementation partitioned, and if so why is it showing latencies consistent with an unpartioned implementation?
3) Is the feature list in the first post accurate?  Are there additional features, or alternatively are some features on that list no longer supported.

I have a few other questions as well about MC's automatic resampling of filters (I've never gotten it working, but it obviously works for some people), but I'll wait to get those answered until mattkhan's issues are sorted.

EDIT: ninja'd, but I'll leave this here.

Honestly I don't even know what a partitioned implementation is.  And I wrote our convolution engine!

Here's a link to some discussion of another partitioned convolver and the i/o latency reductions anticipated: http://www.ludd.luth.se/~torger/brutefir.html#bruteconv_3

[mattkhan]

Honestly I don't even know what a partitioned implementation is.  And I wrote our convolution engine!

brutefir is one such implementation, they describe it here - http://www.ludd.luth.se/~torger/brutefir.html#bruteconv_3

it basically makes it much faster at a cost of much more CPU, the combination of this with the WDM driver seems like a good one as it means convolution might become a feasible option. Sounds like a nice technical challenge for you

[mwillems]

brutefir is one such implementation, they describe it here - http://www.ludd.luth.se/~torger/brutefir.html#bruteconv_3

it basically makes it much faster at a cost of much more CPU, the combination of this with the WDM driver seems like a good one as it means convolution might become a feasible option. Sounds like a nice technical challenge for you

Hilarious, we both went to the exact same link 

[BradC]

I'm another user that would appreciate a partitioned implementation to help with multichannel convolution and the WDM driver.

If you wanted to get real fancy, sending many parallel fft/ifft to the gpu would probably get good performance and take the load off the CPU.

[mattkhan]

bringing this thread back from the dead as I thought it was appropriate rather than starting a new one (which would be a bit of a random thread that goes something like "hey this feature you say you have, it works you know"  )

perhaps an admin could move this thread to the v21 board?

On 1) mattkhan and I haven't been able to get input channel weights working.  
....
The questions are:  
1) Is channel weighting/scaling in config files supported (whether input or output)?

I thought I'd bump this thread back up as, after a couple of comments on the acourate mailing list, I can report that this does work on the input side. For example, assuming a 2 channel input and output format set to 4 channel then the following work as expected

Reroute 1 to 3 & 2 to 4, attenuate each channel by 12dB

Code: [Select]

48000 2 4 0
0 0 0 0
0 0 0 0
C:\Users\Matt\Documents\Acourate\Investigations\cfgrouting\unity-12.wav
0
0.25
2.0
C:\Users\Matt\Documents\Acourate\Investigations\cfgrouting\unity-12.wav
0
1.25
3.0

route 1 to 3 and sum 1 & 2 into 4

Code: [Select]

48000 2 4 0
0 0 0 0
0 0 0 0
C:\Users\Matt\Documents\Acourate\Investigations\cfgrouting\unity-12.wav
0
0.0
2.0
C:\Users\Matt\Documents\Acourate\Investigations\cfgrouting\unity-12.wav
0
0.0 1.0
3.0

route 1 to 3 and sum 1 & 2 into 4, attenuate all input channels by 12dB

Code: [Select]

48000 2 4 0
0 0 0 0
0 0 0 0
C:\Users\Matt\Documents\Acourate\Investigations\cfgrouting\unity-12.wav
0
0.25
2.0
C:\Users\Matt\Documents\Acourate\Investigations\cfgrouting\unity-12.wav
0
0.25 1.25
3.0

Output scaling does not work though, i.e. something like this

Code: [Select]

C:\Users\Matt\Documents\Acourate\Investigations\cfgrouting\unity-12.wav
0
0.0
2.25

silently ignores the 12dB attenuation. FWIW I don't think this matters at all as you can just use a peq block to implement that attenuation (whereas per path input scaling cannot be replicated and has to be baked into the filter).

I think the reason why I couldn't get to this work previously is some, potentially odd, behaviour concerning the timing of when jriver reloads a cfg file (which I have raised in a separate thread, see http://yabb.jriver.com/interact/index.php?topic=102394.0)