Print

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

[Paulv]

after investigation: yes audacity can export to wav, any format
thanks for your help
Paul

[hulkss]

I seem to have some processing issues

I remember you said you were running 132k filter taps. Try half that. I noticed if I specify 65K taps in Audiolense I get 132k as reported by convolverVST, so I ask for 32k taps in Audiolense. Bernt is looking into it. We are using way more taps than necessary.

With high bit resolution in the convolver, 48k rate filters are plenty good too.

[AudioVero]

Number of taps
The number of taps or filter length defines the frequency resolution of the FIR filter. The resolution is samplerate/taps. So a 64k filter @ 44.1 kHz samplerate gives a frequency resolution of 0.6729 Hz. A 128k filter thus gives 0.336 Hz frequency resolution. The high resolution is definitely overkill for the mid to high frequency range but good for the low frequency range.
The high number of taps has in some way started with Brutefir by using long filters without compromise. I have customers using even 256k filters and they swear to have a better result in the bass range.
Another solution is using multirate filters. But splitting the frequency range in several bands also has its disadvantages, especially with phase correction.

Raw format
It simply means a headerless sequence of filter taps either in single or in double precision format. Typcally .raw or .pcm files are single precision files (32 bit float), whereas .dbl files are double precision files (64 bit float). So e.g. .dbl is the standard format of Acourate but it can also be converted simply to 32 bit or 64 bit wav files. Brutefir, Convolver or Inguz all allow raw filter formats.

[Trumpetguy]

I remember you said you were running 132k filter taps. Try half that. I noticed if I specify 65K taps in Audiolense I get 132k as reported by convolverVST, so I ask for 32k taps in Audiolense. Bernt is looking into it. We are using way more taps than necessary.

With high bit resolution in the convolver, 48k rate filters are plenty good too.

True, I have been in contact with Bernt about this, there is something strange about filter lengths in AL. I was informed he was looking into it and it should be fixed in AL 4.3.

Right here and now, I do not remember number of taps in my filter, I could test with a shorter one. My main room problems are in the bass region, and as AudioVero points out, higher number of taps give better resolution in the bass range.

EDIT: The strike-out text is simply wrong and gives the wrong impression of my AL filters. There is nothing wrong with them, I have been using them for two-three years. What the uncertainty is about is that I am not 100% if the latest AL version gives the wanted filter length or not, since there was an unhandled exception when generating a few filters. Normally, I would not care if the filter is 65k or 132k, so I simply picked a filter length that gave an filter file as output. As stated above, this exception thing is going to be corrected in the next AL build. Sorry for any misunderstandings caused by this.

[AudioVero]

A filter with 64 k taps or 65536 coefficients in double precision float has the file size of 65536 * 8 bytes = 524288 bytes = 512 kB. In single precision representation it has the file size of 256 kB. This is with a raw = headerless file. In case of another file format like e.g. wav there will be some more bytes. In case of compression like flac of course the file size will be smaller.

But typically all you need to know is the file size and the precision to know about the filter length. No scerets here. So I wonder about the trouble with filter lengths. Oh, theoretically a file may also contain filters for multiple channels. So you need also to know about the channel number. The 64 k example is valid for one channel.

[Trumpetguy]

A filter with 64 k taps or 65536 coefficients in double precision float has the file size of 65536 * 8 bytes = 524288 bytes = 512 kB. In single precision representation it has the file size of 256 kB. This is with a raw = headerless file. In case of another file format like e.g. wav there will be some more bytes. In case of compression like flac of course the file size will be smaller.

I have stored the filters as 32bit float. How would I know double or single? I can probably import the wav file into Matlab to analyse it.

No scerets here. So I wonder about the trouble with filter lengths.

No trouble really, just never thought of it. And there may be a mismatch between user choices and actually created filter length in AL in the current version. I don't know that, but there are indications. GUI issue, I guess.

[AudioVero]

How would I know double or single? I can probably import the wav file into Matlab to analyse it.

You can e.g. import the file as raw data file in Audacity. There you can select between PCM, single float, double float, little or big endian and so on. You will see the result directly and know what format makes sense.

[thomaspf]

Just saw the convolver support announced your MC17 email.

A couple of years ago I pushed for a native VST host to get access to a stable convolver for Uli's Acourate. I have been using that for years and the term humbling that was used in an earlier post probably describes it best.

There is little point in spending mega $$ on electronics and speakers if the room interactions reduces the result to a mess. Initially my success was limited since my room was so bad. I spend some time with F. Alton's Master Handbook of Acoustics to get to a halfway balanced RT60 across the frequency and then a much longer time convincing my wife to get the acoustical elements integrated into our living room. After that and JRiver offering a VST host things went smooth.

Uli kept improving Acourate and the accuracy of my playback chain followed that evolution. I have tried all open source packages but I have found nothing that sounds as natural and transparent as Acourate. It is like the sounds snaps into focus and the timbre of voices and intruments is fully preserved. The price looks a bit high initially but I got the benefit of a trial correction impulse and when I saw that the correction has more impact than any multi thausend dollar electronics would have I figured it is definitely worth the price of admission.

So far I have been using Pristine Space which has worked well for me over the last couple of years but I will definitely try this out and see whether I can switch over. In fact I am in the process of building a system for my son and I will set it up with your convolver.

Cheers

    Thomas

[Trumpetguy]

For 2ch music the new convolver is working like a charm! That is GREAT, thank you so much 

For multichannel music and movies and music my cpu seems to be too weak, forcing me to stick to ConvolverVST until either the new convolver has some feature reducing cpu intensity or I have set up a new htpc. Both are equally welcome!

[Matt]

For multichannel music and movies and music my cpu seems to be too weak, forcing me to stick to ConvolverVST until either the new convolver has some feature reducing cpu intensity or I have set up a new htpc. Both are equally welcome!

I spent some time testing with your filter set.

I got the SSE3 going a little faster (about 5%), but you're probably still out of luck for 15 paths on a JRMark 1300 machine.  I think ConvolverVST is at an advantage here since it uses 32bit instead of 64bit precision.  That means it can use SSE to do 4 operations a cycle instead of 2 like 64bit allows.  It also means it's processing half as much memory.  However, I would hope most in this thread consider our 64bit pipeline worth the performance penalty (I do).

As a frame of reference, my i7 work machine runs your 15 path filter @ 96 kHz at about 5.7x realtime.  Since that's only really one of the four cores, it's just no sweat on a machine like that.

[jdubs]

However, I would hope most in this thread consider our 64bit pipeline worth the performance penalty (I do).

Heck yeah!!!   

-Jim

[Trumpetguy]

I spent some time testing with your filter set.

I got the SSE3 going a little faster (about 5%), but you're probably still out of luck for 15 paths on a JRMark 1300 machine.  I think ConvolverVST is at an advantage here since it uses 32bit instead of 64bit precision.  That means it can use SSE to do 4 operations a cycle instead of 2 like 64bit allows.  It also means it's processing half as much memory.  However, I would hope most in this thread consider our 64bit pipeline worth the performance penalty (I do).

As a frame of reference, my i7 work machine runs your 15 path filter @ 96 kHz at about 5.7x realtime.  Since that's only really one of the four cores, it's just no sweat on a machine like that.

Thanks for testing. As long as there is a reasonable explanation for the increased cpu usage, I have no problems accepting that I such processing  would require relatively new hardware. After all, my AMD Athlon X3 cpu and motherboard are four years old, and I am looking at a watercooled i7 3.4GHz, new motherboard and 4x4GB RAM. Believe that will do.

The functionality of the new convolver + 64bit processing makes this a simple decision 

[Trumpetguy]

However, I would hope most in this thread consider our 64bit pipeline worth the performance penalty (I do).

In Audiolense, the user can specify 16int, 24int or 32float measurements. With the 64bit pipline in JRiver, is the lower bit depth of the DRC filter a bottleneck in any way?

[JimH]

I split some posts to a topic called Microphone measurements for convolution setup

[TheLion]

 However, I would hope most in this thread consider our 64bit pipeline worth the performance penalty (I do).

Most definitely worth it. That was my whole point starting this thread. No taking shortcuts for the sake of performance please!

@ Trumpetguy : Until you get your HTPC upgrade simply reduce the filter resolution. I find that going from 131k to 66k tabs gives about 33% faster processing with JRiver Convolution. Try using 33k tabs with Audiolense.

[Trumpetguy]

@ Trumpetguy : Until you get your HTPC upgrade simply reduce the filter resolution. I find that going from 131k to 66k tabs gives about 33% faster processing with JRiver Convolution. Try using 33k tabs with Audiolense.

I will.

[TheLion]

@ Matt


I have another feature request ;-)

Right now I have the following situation: I use 131k tab filters for each sampling rate (individual filter optimized by Acourate or Audiolense for each sampling rate give better results than one filter resampled by your engine - especially in high frequency response). I guess most Acourate/Audiolense users will generate individual filters for each sampling rate. So this is a common situation. With that I have two rather annoying problems with your Convolution:

- First I need to manually switch filters depending on the input sampling rate (to avoid filter resamling). It would be great to have filter banks for each sampling rate. How about assigning filters for each sampling rate in "Output Format" - "Sampling Rate" as new column when Convolution is used? This can be used not just for filters with different "native" sampling rate but also for other channel configurations (for 44.1khz content use a 2.0 setup without XO, for >=48khz a 5.1/7.1 filter) or target curves (for 44.1khz music content a flat target, for >=48khz a little more bass emphasize). What do you think? 

- Second I have a huge problem with video delays. eg. If I play 48khz content the inherent filter delay is double compared to 96khz (given the same filter resolution). So I always need to manually double the video delay when switching to content with half the sampling rate. It would be great to have MC make this necessary changes of video delay all by itself. Or "simply" add the option of video delay depending on sampling rate.

I consider these two features essential for the usability of convolution. Thank you very much!   

[TheLion]

btw since JRiver Convolution supports the delay settings in my config files just like ConvolverVST the difference in soundstage that I described earlier in this thread is gone for good. They still sound slightly different but IMHO JRiver Convolution is at least as good if not "better". From now on I use your Convolution as my reference! Amazing work in unbelievable time, Matt!

[lasker98]

TheLion:
I'm trying to follow what you're doing. If I understand, you want J River convolver to automatically select the correct filter for the sample rate of the track you're playing? If this is correct, I think it's doing that now.
I use the following .cfg file:

c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_441.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_48.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_882.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_96.cfg

When this file is loaded in J River convolver, the correct filter is loaded for each track's sample rate, at least based on what "Audio Path" is telling me. My dac also indicates the current sample rate and this also appears correct for each track. I hope that I'm correct in thinking that J River is automatically switching filters for the different sample rates.

When I saved my filter in Audiolense, I saved in 44.1, 48, 88.2 and 96kHz, giving me 4 separate files. For example, here's my 44.1 .cfg file, corresponding to "c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_441.cfg" from above:

44100 2 2 0
0 0
0 0
C:\Users\Bill\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\Kitch_panels_001 441.wav
0
0.0
0.0
C:\Users\Bill\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\Kitch_panels_001 441.wav
1
1.0
1.0

Assuming I'm even talking about the same thing as you, couldn't you make a similar  .cfg file pointing to each of your desired filters, then make a .cfg file like the first one I posted pointing to each of those files, then load that into J River convolver?

If this isn't what you mean, my apologies and I'll go back to trying to follow what you're trying to accomplish.

Bill

[TheLion]

ATM JRiver Convolution isn't autoselecting filters based on sampling rate. It resamples any filter you select to the sample rate of the input stream. This is working flawlessly but isn't optimal regarding sound quality. See Uli's (audiovero) posts - Acourate and Audiolense for that matter optimize when outputting for different sampling rates using some smart methods to deal with the different Low-Pass.

Convolver config file format supports "autoselecting based on sampling rate" but I don't think JRiver is supporting this feature yet.

[Trumpetguy]

@ Trumpetguy : Until you get your HTPC upgrade simply reduce the filter resolution. I find that going from 131k to 66k tabs gives about 33% faster processing with JRiver Convolution. Try using 33k tabs with Audiolense.

15 paths filter 8channel out: Reduced number of taps from 131k to 32k increased convolution speed from <1.0x to ~2.5x real time. Which will probably do for movies while waiting for new htpc parts.

[lasker98]

Now I'm lost. If I load my .cfg file:

c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_441.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_48.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_882.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_96.cfg

and you say J River convolver isn't autoselecting the filter, then how exactly does that .cfg file work? If I understand your response, you're saying J River is only using one filter, but internally modifying that filter to conform to the sample rate of the input stream? So in the above file, which of those 4 files is J River actually using?

When I was using convolvervst, I would load the .wav file for say, 96 kHz filter, then set J River output mode to resample everything to 96 kHz. This was my workaround for playback of different sample rate files in old convolvervst.

If I loaded a .cfg such as the one shown above into convolvervst and had J River output mode set to no resampling, J River/convolvervst would play 44.1 files fine, but as soon as a file came up to play in anything but 44.1, playback would stop and there would be a popup message about different input and output sample rates.

Now, based on your explanation of how J River convolver is working, I have no clue what's actually happening with playback. At least J River convolver will play the different sample rates without stoppping but what's it's actually doing seems to be a mystery.

Bill

[Matt]

Now I'm lost. If I load my .cfg file:

c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_441.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_48.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_882.cfg
c:\users\bill\documents\juice hifi\audiolense 4.2\correctionfiles\kitch_panels_001 2.0_96.cfg

and you say J River convolver isn't autoselecting the filter, then how exactly does that .cfg file work? If I understand your response, you're saying J River is only using one filter, but internally modifying that filter to conform to the sample rate of the input stream? So in the above file, which of those 4 files is J River actually using?

We will use whatever cfg file you select, and resample it if needed to support other sample rates.

I would recommend picking your highest quality cfg file, "kitch_panels_001 2.0_96.cfg" in this case.

Someday we may support switching filters based on sample rate.  I'm still trying to understand the technical merits for that approach as opposed to downsampling using our resampler (which has quite a good reputation).

[Matt]

- I have a huge problem with video delays. eg. If I play 48khz content the inherent filter delay is double compared to 96khz (given the same filter resolution). So I always need to manually double the video delay when switching to content with half the sampling rate.

The delay from convolution does not change with sample rate (we partition to avoid that).

And the filter delay should not change either -- when we resample, no timing information changes.

So I'm not understanding what you're describing.  It might be worth starting a new thread to discuss it.

[TheLion]

The delay from convolution does not change with sample rate (we partition to avoid that).

And the filter delay should not change either -- when we resample, no timing information changes.

So I'm not understanding what you're describing.  It might be worth starting a new thread to discuss it.

Matt,

when using individual filters per sampling rate (not using your filter resampling) the filter delay (and therefor the necessary video delay to compensate) doubles when you cut sampling rate by half. Eg. a 48khz filter has double the filter delay than a 96khz filter with the same filter resolution. If you double the filter resolution (eg. 131k taps instead of 66k) the filter delay doubles. Therefor a 48khz 66k tap filter has the same filter delay as a 96khz 131k tap filter.

 

[Matt]

Matt,

when using individual filters per sampling rate (not using your filter resampling) the filter delay (and therefor the necessary video delay to compensate) doubles when you cut sampling rate by half. Eg. a 48khz filter has half the filter delay than a 96khz filter with the same filter resolution. If you double the filter resolution (eg. 131k taps instead of 66k) the filter delay doubles. Therefor a 48khz 66k tap filter has the same filter delay as a 96khz 131k tap filter.

There are two delays:
1) Convolution delay
2) Delay baked into your filter

#1 is handled automatically by Media Center.

#2 should not change when resampling a filter.  Resampling changes the sample position, but since the frequency of samples changes by the corresponding amount, the position with regards to time is unchanged.

[BradC]

TheLion,

There is a bit of a mix up in terminology in your post.
Namely, a 65k tap filter at 48KHz has the same (frequency) resolution as a 131k tap filter at 96kHz.
When you go from 65k taps at 48kHz to 65k taps at 96kHz you halve the resolution and halve the processing latency
So the required latency correction is determined by the frequency resolution of the filter.
What you are saying is correct, but the terminology was confusing.

[AudioVero]

Maybe I can help in the discussion.
If MC changes the filter samplerate e.g. from 48 kHz to 96 kHz then the number of taps is twice the number before conversion. With a symmetric linear phase filter the delay from filter start to the filter center is the same for both samplerates. This is ok.
TheLion is talking about filters created by Acourate. Here the filter length is cut by standard to a length of 64k taps. In both cases the 48 kHz and 96 kHz filters are still symmetric. Thus the delay of the 96 kHz filter is half of the 48 kHz filter delay. That's why the config files for different samplerates need different delay parameters.

Of course now someone will argue for a filter samplerate conversion carried out by MC. The problem: let's start with a filter @48 kHz. A 192 kHz track thus needs a converted filter with a filter length by factor 4. So a 64k filter will upsample to 256k. This result in a higher CPU load, maybe too much for the CPU. In addition the original filter is just defined up to 24 kHz. So the 192 kHz filter will have a stopband from 24 kHz to 96 kHz (fs/2). So the frequency content of high resolution music tracks above 24 kHz will be suppressed. This is not desired. Why to use high resolution tracks then? Acourate does a special conversion. The SRC algorithm includes a brickwall extension. So all frequencies above 24 kHz will pass unchanged, only the gain is adjusted properly to the filter gain below 24 kHz.

On the other side we can start with a 64k filter @192 kHz. So when we downsample the 48 kHz has 16 k taps. The resolution is lower than with 64k of course.

At the end we end up with some balancing. We use 64k taps @ 48 kHz. We may use 128k taps @ 96 kHz if the CPU power allows to do so. And we may use even up to 256k taps filters. But if the CPU power is not enough (think about silent computers with passive cooling e.g.) then we will come to filters of different sizes. That's why there is a requirement to allow different config files for different samplerates.

[TheLion]

Thanks for the great explanation Uli!

For the time being I will use 64k taps filters with 44.1/48khz, 128k taps 88.1/96khz and 256k taps for 176.4/192khz. I still need to manually change the filters but I can keep the video delay constant this way.

[)p(]

Anyone else experience clipping with .68 and later?

When I have volume leveling enabled all is ok but when I disable it I get occasional clipping/distortion on very loud tracks even with clip protection enabled. I have checked the normalize option.

[AudioVero]

Today many tracks are mastered near to 0 dBFS (full scale) due to the loudness war. About 75% of all CDs show intersample clipping (= the interpolated curve between the samples is higher than 0 dBFS). In addition correction filters that also change phase can cause clipping because the crest factor of the music signal is changing by phase shifts. With online filtering the algorithm needs to react on clipping in realtime. The most simple algo is to cut limit all signal amplitudes to max 0 dBFS. A compression algorithm is possible but it can also introduce pumping effects. Of course it is also possible to create some headroom by attenuating the music signal with a certain gain factor, e.g. -3 dB.

Intersample clipping: with an artificial signal it is possible to demonstrate a clipping between samples of even about 12 dB !

[TheLion]

May I ask for your kind participation: http://yabb.jriver.com/interact/index.php?topic=69341.0

[TheLion]

Today many tracks are mastered near to 0 dBFS (full scale) due to the loudness war. About 75% of all CDs show intersample clipping (= the interpolated curve between the samples is higher than 0 dBFS). In addition correction filters that also change phase can cause clipping because the crest factor of the music signal is changing by phase shifts. With online filtering the algorithm needs to react on clipping in realtime. The most simple algo is to cut limit all signal amplitudes to max 0 dBFS. A compression algorithm is possible but it can also introduce pumping effects. Of course it is also possible to create some headroom by attenuating the music signal with a certain gain factor, e.g. -3 dB.

Intersample clipping: with an artificial signal it is possible to demonstrate a clipping between samples of even about 12 dB !

The described Intersample Clipping is a nice argument for using AcourateNAS offline convolution. If Stereo only is fine and you never touch your speaker setup/placement or room interior ;-)

[RC23]

IMHO we have also to think about active speaker systems, we should not forget them. (*)
So if e.g. a stereo signal feeds 3 channels for each side (this is of course also supported by Convolver VST) then it may become difficult just to talk about speaker distances. How do you measure the distance to the acoustic center of a midrange driver compared to a tweeter? By a folding ruler ?    Indeed we find "distances" or better delays of just one sample. That's why e.g. Brutefir is defining the delays in samples (and subsamples).

The best way is to let the user select the unit, either feet or meter or millisecond or samples. So he chooses what is best to his opinion.

We always have to delay the quicker sound (a tweeter or a closer speaker). So also IMO it is best to treat a delay by its definition and to avoid inverse delays.   Simply define the delay for the slowest unit/device/driver as 0 and refer to it with the other units/devices/drivers.

(*) PS: IMO this is also a good example why the strict channel assignment in the room correction option is confusing. At least for me. The active speaker channels have nothing to do with front, lfe, surround channel or back channel.

I would like to support the comment of Uli regarding the units of delay (feet or meter or millisecond or samples). My loudspeaker setup will be a 3-way-system plus subwoofer in combination with Acourate.

Ruediger

[Scolex]

WOW that was a lot of information I think my brain has indigestion.

Does anyone know of a place where a person could send a mic so a calibration file can be created.

[zydeco]

I've just seen this thread - it's great that JRiver is now natively supporting convolution. I'm just finishing some 4-way active speakers and have developed filters using Acourate to cater for the left / right woofer, bass, mid and high channels. Is this multi-channel process supported within the convolution plug-in? And, if so, then how is the output set-up?

Zydeco

[markus_kr]

Is this possible?

i heard about convolver support a few years ago. At the moment I have a 4-way active system running, the filters coming from audiolense XO. This setup realises a dream which I had since the beginning of this millenium.

But one thing I very often miss:
2 or better 3 buttons for preloading *.cfg files in the convolver dsp menue. The button would activate the loaded file.  By clicking another button the previous file will be activated.

With that functionality, an online comparison of different measurements, target curves and so on is possible. This would be the most important  thing to decide the quality of different filters, and it is my greatest wish for JR  (just behind an input for my record player or CD player - which seems impossible ...)

Thanks in advance for answering

markus

[TheLion]

WOW that was a lot of information I think my brain has indigestion.

Does anyone know of a place where a person could send a mic so a calibration file can be created.

Here you go: http://www.cross-spectrum.com/measurement/mike_meas.html

[TheLion]

Matt - is this possible?

i hear with comvolver support a few years meanwhile. At the moment I have a 4-way active system running, the filters coming from audiolense XO. This setup realise me a dream which I had since the beginning of this millenium. But one thing I very often miss:

2 or better 3 buttons for preloading *.cfg files in the convolver dsp menue. The clicked button activates the loaded file.  By clicking another button the preloaded file will be activated.

With that functionality an online comparison of different measurements,target curves and so on is possible. This would be the most important  thing to decide the quality of different filters, and it is my greatest whis for JR  (just behind an input for my record player or CD player - which seems impossible ...)

Thanks in advance for answering

markus

Markus,

if you read a few pages back I already "requested" the feature of different filter banks with (gapless) switching between them. But it is already great atm that JRiver Convolution doesn't go mute while selecting a new filter (ConvolverVST does that). So the music keeps playing while selecting a new filter and the switching is therefor pretty instantaneous.

I am sure Matt will consider this in the future.

[markus_kr]

lion,

thx for answering, I wasn't aware about that. Switching the filter while playing makes it possible to compare different filters detailed.

best regards
markus

[TheLion]

The next step...

MC audio engine (incl. all DSP studio filters like Convolution) as Virtual Soundcard, with the ability to route any external source from the ADC inputs through it as well.

A thread reviving an old ongoing discussion about this concept has opened recently: http://yabb.jriver.com/interact/index.php?topic=69354

Basically this would allow to use convolution for any internal and external audio stream. Therefor every audio stream on your computer (from any kind of application) as well as any external source (like TV receivers, SACD players,...) would be covered.

[Mitchco]

We will use whatever cfg file you select, and resample it if needed to support other sample rates.
 
I would recommend picking your highest quality cfg file, "kitch_panels_001 2.0_96.cfg" in this case.
 
Someday we may support switching filters based on sample rate.  I'm still trying to understand the technical merits for that approach as opposed to downsampling using our resampler (which has quite a good reputation).

 
Hi Matt, just wanted to say thank you so much for adding native convolution to MC!  Wrt to above, I have source material ranging from 192KHz to 44.1KHz.  Are you recommending that I use a 192KHz filter? Or is picking a median like 96KHz the recommended approach?
 
I know that the ConvolverVST format supports multiple sample rates stored in one config file as a filer list: http://convolver.sourceforge.net/config.html  Scroll down to Filter list near the bottom to show how it is implemented.  I had tried this with ConvolverVST but could not get it to work...  I guess it boils down to is there sound quality difference in resampling?
 
On another note, when playing my "hottest" mastered track, with normalize filter volume checked on, I reach about 46% peak overall for the song.  Other tracks that are not mastered as hot sometimes never reach above 10% peak.  Am I "doing it wrong"? Or is there another way to makeup the gain?  In ConvolverVST there is the attenuation slider that allowed manual gain makeup.
 
Best regards,  Mitch
 
 

[hulkss]

Matt,
The new JRivolver is working OK with my configuration and filters. It is about 4 times slower though (realtime x 8 vs x 30). I have multiple inputs on the last three paths and JRivolver counts each one as a path (maybe processing that way too?). ConvolverVST reports 19 paths and JRivolver says 37 paths. The 7 inputs per path should be combined and then convolved I would think?

The config file:
48000 8 16 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
0
0.0
0.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
1
0.0
1.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
2
0.0
2.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
3
1.0
3.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
4
1.0
4.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
5
1.0
5.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
6
2.0
6.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
7
2.0
7.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
8
2.0
8.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
9
3.34
9.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
10
4.0
10.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
11
5.0
11.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
12
6.0
12.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
13
7.0
13.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
14
3.33
14.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
15
3.33
15.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
16
0.34 1.34 2.34 4.34 5.34 6.34 7.34
9.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
17
0.33 1.33 2.33 4.33 5.33 6.33 7.33
14.0
C:\Users\Brad\Documents\Juice Hifi\Audiolense 4.2\CorrectionFiles\T-HouseCurve F-HomeTheater M-Center 48.wav
18
0.33 1.33 2.33 4.33 5.33 6.33 7.33
15.0

[hulkss]

I don't know how the FFT's (Fast Fourier Transforms) are solved in JRevolver but Convolver uses: http://www.fftw.org/
Being curious, I downloaded the latest 32 bit Windows package (v3.3) and replaced the much older version in the Convolver program folder with the new DLL of the same name. It worked and I got a speed increase of 25% with ConvolverVST.

I also installed the latest 32 bit version of  the libsndfile DLL http://www.mega-nerd.com/libsndfile/

Granted this is 32 bit solving but it is about 4 times faster than JRivolver (in my set-up). Check it out if you have limited computing power or want to reduce latency.

[AudioVero]

It seems that now we are getting more and more close to the interesting points of a convolution application.  
There are already different required features for the system and I'm very curious how all of them will be carried out.

So Hulkss has shown his 19 filters - 37 paths example. The high number of filters is necessary by multichannel or multiyway systems or even more by combined multichannel/multiway system. The users expect the best accuracy, thus double point precision is the basic layout. Of course it is a question to use the best available mathematical methods to keep the CPU load as low as possible and to get the realtime factor as high as possible. This may include using a sophisticated and specialized math library like FFTW or Lapack (IMHO it will be very difficult to create a better FFT-solution).

As I've already written in a previous message people expect individual filters for different samplerates and also the possibility to switch online between different filters.
E.g. the Hulkss example would thus result in a managment of 342 filters in total (19 filters x 6 samplerates x 3 filterbanks).

Typically we use 65536 filter taps with 44.1 and 48 kHz samplerate. To keep the frequency resolution the same a 88.2/96 kHz filter requires 131072 taps and a 176.4/192 kHz filter need 262144 taps. So with high resolution audio and non-compromise filters we have a real challenge for the convolution engine.

Oh, we can even easily enlarge the challenge: this will happen in case of a zero-latency convolution with non-uniform partition sizes running in multiple threads.  

Last but not least :
If beside the "normal" playback and streaming MC would manage the handling of external sound signals (soundcard input) then we have the ultimate playback engine   But I guess this will take some time. A "simple" convolution is developed quickly. But a sophisticated solution takes some more time.

PS: I have forgotten a wish. If MC also would behave like a virtual audio driver then it can get the sound stream from other applications, theoretically even from competing players. Imagine a Foobar playback by the MC audio engine  With a virtual audio driver a bitperfect playback is a new challenge as the driver needs to collect the data before the kmixer.

[Matt]

Matt,
The new JRivolver is working OK with my configuration and filters. It is about 4 times slower though (realtime x 8 vs x 30). I have multiple inputs on the last three paths and JRivolver counts each one as a path (maybe processing that way too?). ConvolverVST reports 19 paths and JRivolver says 37 paths. The 7 inputs per path should be combined and then convolved I would think?

Could you zip that whole package up and email it to me?  I'm matt at jriver dot com.

I think you're right that adding the inputs together and doing convolution on the result would be faster.  Currently we're not doing that.  The FFT and iFFT only happens once per channel (if needed by that channel), but we're doing convolution against each input FFT instead of combining the inputs and doing convolution on the result.

Thanks.

[hulkss]

If MC also would behave like a virtual audio driver then it can get the sound stream from other applications

Yes, I would like this capability for playing test or measurement signals through the entire audio chain.

[soongsc]

I would like to bring attention to work done here.
http://www.bodziosoftware.com.au/
Since I use version 2, I can say it is great.
Would there be possibilities to make a smooth integration?  I know the author looked at JRiver site but could not find a way for seamless integration.

[bruce.weiland]

I was really hoping nobody would be using something like Dynamic Range Compression by now. So I consider the acronym DRC to be free from bad meanings ;-)

btw in your country it has a great meaning: http://www.drc.de/

Sony has used it for many years.  "DRC" was developed in 1997 as a technology that can convert a standard television signal format to a high-definition signal format, based on the concept of establishing a higher resolution signal format from scratch.  ie  480i to 960i, latest version goes to 1080p.

So, at least two uses of the acronym.


Bruce

[Matt]

Thanks to hulkss for the 16-channel sample.  In a coming build:
Faster: Improved how Convolution operates when a filter operates on multiple input channels (should give a 10-25% speedup in these cases).