Keith_W DSP system

[JanRSmit]

I have VituixCAD installed on my PC. My IQ = 50 brain finds it a bit too difficult to use. Another friend suggested I use AKABAK. That is even harder to use.

Regardless, you are right. It is time to add more tools to my arsenal. I am limited by my inability to make models so it is time to fix that.

What is the first objective for use of vcad? Perhaps i can help you to start.

 

[mdsimon2]

Yes it can. But I still prefer to take a proper nearfield measurement for phase correction. At MLP I do a much gentler correction for the upper freqs.

Very cool, that is an awesome feature!

I asked him to create a model for my 10cm measurement (green) and MLP measurement (brown). Then I inverted the 10cm measurement and convolved it with my 10cm nearfield measurement to get the actual driver response. Then I convolved that with the 10 foot measurement to get the predicted measurement at the MLP. I then compared it with the actual MLP measurement:

I think you may have a typo here which is making it difficult for me to understand. I think you mean to say "I inverted the 10 cm measurement modeled baffle step response and convolved it with my 10 cm near field measurement to get the actual driver response". I think you were trying to eliminate the baffle step present in your 10 cm measurement and then take the near field response without baffle step and convolve it with the far field field baffle step response. That is roughly correct, but I think it would be better to start with true near field data and then add in the far field baffle step response.

There is another elephant in the room, near field data is not accurate for higher frequencies and this is why the quasi-anechoic measurement tutorials have you merge / splice far field measurements (typically taken at 50-200 cm) to near field measurements + baffle step. The error in the high frequency roll-off by only looking at near field measurements will corrupt correction you do on a driver basis. My understanding is that most of the recommendations about near field vs far field measurements seen in modern tutorials are from this 1974 Keele paper -> https://pearl-hifi.com/06_Lit_Archive/14_Books_Tech_Papers/Keele_D_B/LF_Near-field_Measurement.pdf. Figure 10 is interesting as it shows the differences between different measurement methodologies. You can also see some pretty big differences at high frequencies between your 2 cm and 10 cm measurements as well as modeled (pink) vs measured (black) responses.

All that being said, it would be interesting to compare the differences in correction using your current approach vs starting from near field + baffle step + far field. Does it all come out roughly the same after MLP correction? I think they would end up quite different but would love to test that hypothesis.

Michael

 

[Keith_W]

What is the first objective for use of vcad? Perhaps i can help you to start.

The objective is to make a model of my speaker so that I can see if modelled performance is the same as measured. I am well aware that a model is only as good as its inputs, and some of these inputs might be very difficult to obtain. For example, I can't think of a way to measure the flare of my horn. Maybe I could take some stiff wire and bend it until it fits and then somehow try to work out its geometry. How would I know, like I said i'm not blessed with brains.

As has been pointed out by a few posters, I need electrical measurements and TS params of my drivers. Right now I do not know how to take electrical measurements of my drivers. Also something I need to learn, although I never thought that information would be of any use to me - which is why I haven't bothered learning to take those measurements!

Very cool, that is an awesome feature!

Acourate is awesome. It does not force you into a particular workflow. You take the measurements you want, you do the corrections you want. In fact you can do almost anything you can think of - it is so flexible. But you have to come up with the workflow, and decide if it makes sense. I don't think there are any competing DSP products which are as flexible. As you have seen, I was able to take a curve in .FRD format generated by another program and incorporate it into my Acourate workflow. I could ignore Acourate's usual bass management procedures and use MSO if I wished.

I think you may have a typo here which is making it difficult for me to understand. I think you mean to say "I inverted the 10 cm measurement modeled baffle step response and convolved it with my 10 cm near field measurement to get the actual driver response". I think you were trying to eliminate the baffle step present in your 10 cm measurement and then take the near field response without baffle step and convolve it with the far field field baffle step response. That is roughly correct, but I think it would be better to start with true near field data and then add in the far field baffle step response.

You are right, I made a typo. Sorry!

I also started a thread in the Acourate forum where I credited you with giving me the idea. Good to see that Dr. Bruggemann seemed to approve of it.

There is another elephant in the room, near field data is not accurate for higher frequencies and this is why the quasi-anechoic measurement tutorials have you merge / splice far field measurements (typically taken at 50-200 cm) to near field measurements + baffle step. The error in the high frequency roll-off by only looking at near field measurements will corrupt correction you do on a driver basis. My understanding is that most of the recommendations about near field vs far field measurements seen in modern tutorials are from this 1974 Keele paper -> https://pearl-hifi.com/06_Lit_Archive/14_Books_Tech_Papers/Keele_D_B/LF_Near-field_Measurement.pdf. Figure 10 is interesting as it shows the differences between different measurement methodologies. You can also see some pretty big differences at high frequencies between your 2 cm and 10 cm measurements as well as modeled (pink) vs measured (black) responses.

Thank you for sharing! As you can see from earlier photos of my speaker, high frequencies are handled by the plasma tweeter which is horn loaded.

I did take measurements of the tweeter from various distances as indicated on the legend. Ignore the 0cm measurement (mic at the mouth of the horn). As you can see, the measurement is clipped. I also had a heart stopping moment when I saw a spark jump from inside the horn to the microphone (plasma tweeters have very high voltage!). I thought that I had killed my Earthworks M30 mic! Then I repeated some of the measurements I had taken before and thankfully they still look the same. Phew.

All that being said, it would be interesting to compare the differences in correction using your current approach vs starting from near field + baffle step + far field. Does it all come out roughly the same after MLP correction? I think they would end up quite different but would love to test that hypothesis.

Don't know yet. I'll tell you in a few days.

 

[3ll3d00d]

For example, I can't think of a way to measure the flare of my horn.

You can't model a horn in vcad, hornresp would be the place to go for that. However I struggle to imagine the point of doing that as the speaker exists so the only measurement that matters is the one from reality.

ie it's just the same point again that you need decent quasi anechoic data in order to know how to correct it

 

[mdsimon2]

Thank you for sharing! As you can see from earlier photos of my speaker, high frequencies are handled by the plasma tweeter which is horn loaded.

In this context I was still talking about the woofer response, so high frequency is relative. In quasi anechoic measurements of a woofer you are usually merging near field + baffle data with far field data at roughly 300-500 Hz, above this you are using the far field data. Using near field data for this "high" frequency response of the woofer will impact the woofer / mid crossover design.

Michael

 

[DWPress]

I've found that LibreOffice will work with Excel spreadsheets for work I've done so far - and this is the Mac version of the app.

I love tuning in when @mdsimon2, @Keith_W, @Sokel and others dive deep into this stuff. I learn something new every time.

 

[Keith_W]

Well, I just finished redoing my DSP from the ground up. There were quite a few improvements in my technique, but IMO the biggest improvement came from being more careful with my measurements. I also came up with a couple of new correction methods which I will describe later. I also included the baffle step simulation suggested by @mdsimon2 a few posts up.

Comparing the new correction with the old is pretty astonishing. I thought it was clear before, and now it is even clearer. The secret as to why it sounds so much better isn't really obvious to me when I compare my new and old measurements, but I will have to spend the next few days studying the measurements to see what is going on. But I kid you not, linear phase for the win!

I have a pet theory that pre and post ringing isn't as inaudible as people think. When I have produced filters with copious pre and post ringing, the effect is that the sound is smeared, it becomes a little muddy, or if it happens in high frequencies, it sounds "hashy". The best way I can describe it is that notes seem to bleed into each other, and transient attack seems to be blunted.

I know that psychoacoustic research suggests that the audibility threshold for pre-masking is frequency dependent and is approximately 20ms, and post-masking is about 200ms. But I think it is even shorter than this. Either I am misattributing the smeared sound to pre- and post-ringing, or there is something else hidden in those measurements that I haven't found yet. Of course, I have no proof of my assertion so you don't have to believe me. But MY anecdotal experience says: do everything you can to reduce pre and post-ringing. I don't care if there are published audibility thresholds, I want my correction to be even lower than that. I swear blind that I am definitely hearing something, maybe it's ringing, maybe it isn't, but it was definitely there. And now it's gone, and the sound is SO clear.

I suppose the main difference between old and new is that I am now paying a lot more attention to the time domain. I think this is forgivable because time is harder to understand than frequency. I now check every intervention for pre- and post-ringing. I want it to be as short as possible.

Step response of the verification measurement left (red) and right (green). The pre-ringing is about 6ms and very low amplitude.

This must be the highest ICCC I have ever seen, either on my system or on anybody else's. 98.1%!!!

You can see the phase remains completely linear down to about 130-150Hz, then group delay starts to rise below that.

And finally, the frequency response. If you think those peaks and dips are big, look at the vertical scale.

Other differences in method between my old and new correction include:

- better nearfield measurements. I now check the ETC to guide me how much to gate.
- baffle step compensation via modelling as recently discussed
- all nearfield measurements were standardised with an SPL meter at 75dB. In the past, I played the speakers as loud as I could to improve the SNR while taking measurements. I have since learnt that a longer sweep improves the SNR without pushing drivers into nonlinearity, so now I take quieter sweeps but longer.
- every measurement was checked for distortion before attempting correction.
- I have changed my philosophy on upper frequency correction. The mids/tweeters now get aggressive nearfield quasi-anechoic correction - I straighten out the amplitude and phase. But at the MLP it gets a Toole-like "low Q, broad, tone-control style equalisation" - i.e. VERY gentle.

I have one last improvement up my sleeve. I have long wondered whether measurements from MLP should be taken with/without the sofa. After thinking about it for a very long time (a couple of years!) I now have my answer: for bass, measure with the sofa. For treble, measure without. Then splice the two measurements together and use that for correction. I will try this in the next couple of days.

 

[gfinlays]

Well, I just finished redoing my DSP from the ground up. There were quite a few improvements in my technique, but IMO the biggest improvement came from being more careful with my measurements. I also came up with a couple of new correction methods which I will describe later. I also included the baffle step simulation suggested by @mdsimon2 a few posts up.

Comparing the new correction with the old is pretty astonishing. I thought it was clear before, and now it is even clearer. The secret as to why it sounds so much better isn't really obvious to me when I compare my new and old measurements, but I will have to spend the next few days studying the measurements to see what is going on. But I kid you not, linear phase for the win!

I have a pet theory that pre and post ringing isn't as inaudible as people think. When I have produced filters with copious pre and post ringing, the effect is that the sound is smeared, it becomes a little muddy, or if it happens in high frequencies, it sounds "hashy". The best way I can describe it is that notes seem to bleed into each other, and transient attack seems to be blunted.

I know that psychoacoustic research suggests that the audibility threshold for pre-masking is frequency dependent and is approximately 20ms, and post-masking is about 200ms. But I think it is even shorter than this. Either I am misattributing the smeared sound to pre- and post-ringing, or there is something else hidden in those measurements that I haven't found yet. Of course, I have no proof of my assertion so you don't have to believe me. But MY anecdotal experience says: do everything you can to reduce pre and post-ringing. I don't care if there are published audibility thresholds, I want my correction to be even lower than that. I swear blind that I am definitely hearing something, maybe it's ringing, maybe it isn't, but it was definitely there. And now it's gone, and the sound is SO clear.

I suppose the main difference between old and new is that I am now paying a lot more attention to the time domain. I think this is forgivable because time is harder to understand than frequency. I now check every intervention for pre- and post-ringing. I want it to be as short as possible.

View attachment 432205

Step response of the verification measurement left (red) and right (green). The pre-ringing is about 6ms and very low amplitude.

View attachment 432206

This must be the highest ICCC I have ever seen, either on my system or on anybody else's. 98.1%!!!

View attachment 432207

You can see the phase remains completely linear down to about 130-150Hz, then group delay starts to rise below that.

View attachment 432208

And finally, the frequency response. If you think those peaks and dips are big, look at the vertical scale.

Other differences in method between my old and new correction include:

- better nearfield measurements. I now check the ETC to guide me how much to gate.
- baffle step compensation via modelling as recently discussed
- all nearfield measurements were standardised with an SPL meter at 75dB. In the past, I played the speakers as loud as I could to improve the SNR while taking measurements. I have since learnt that a longer sweep improves the SNR without pushing drivers into nonlinearity, so now I take quieter sweeps but longer.
- every measurement was checked for distortion before attempting correction.
- I have changed my philosophy on upper frequency correction. The mids/tweeters now get aggressive nearfield quasi-anechoic correction - I straighten out the amplitude and phase. But at the MLP it gets a Toole-like "low Q, broad, tone-control style equalisation" - i.e. VERY gentle.

I have one last improvement up my sleeve. I have long wondered whether measurements from MLP should be taken with/without the sofa. After thinking about it for a very long time (a couple of years!) I now have my answer: for bass, measure with the sofa. For treble, measure without. Then splice the two measurements together and use that for correction. I will try this in the next couple of days.

And there was me thinking the ICCC of my nearfield setup was really good :

The bar's been raised. Got to get my main rig up into these realms.....

 

[DWPress]

Really tempting me to finally dip into the Acourate rabbit hole.

 

[Sokel]

I have one last improvement up my sleeve. I have long wondered whether measurements from MLP should be taken with/without the sofa. After thinking about it for a very long time (a couple of years!) I now have my answer: for bass, measure with the sofa. For treble, measure without. Then splice the two measurements together and use that for correction. I will try this in the next couple of days.

If you want to know the pro world practice, last few measurements was not only with the sofa in place but with a guy sitting there as well while those weird signals were playing in sequences from all over the place (mics were hanging from the roof and they were 4 sound sources they used, at equal distances in front of the front wall with drivers all around them)

(that was for the room, right? Not the speakers, I didn't have any speakers of my own in there yet)

 

[hvbias]

In short, it takes the minimum-phase response of a driver and makes it linear phase. This is only possible with linear-phase FIR filters with a lot of taps since it is much easier to manipulate phase and amplitude independently. If you want, you could design a reverse all-pass filter and do it manually (I describe how to do this in my free Acourate guide) but the new macro automates it. Why would you want to do this? The obvious reason is that it makes summation of drivers easier if the phase is not rotating at the corner frequency.

But there may be an audible benefit - there is a long debate on ASR where JJ stated that phase deviation of more than 15 degrees per ERB is audible. I believe him, to my ears, when you get rid of phase distortion, the result is exceptional clarity. In fact most people who listen to my system mention how clear it is. I have a set of filters with and without phase linearisation (as well as some clumsy attempts early on where I inadvertently worsened phase distortion) and the difference between them is easily audible. It is not often that I go against Linkwitz and Toole, but in this case I can really hear the difference, and I kid you not.

Just curious do you feel this improvement in clarity by minimizing phase distortion also applies to rock/pop music? There is a thread on another forum started by a mastering engineer that says "audiophiles don't really want neutral," when discussing it with people in that thread I would say a good 80-90% were heavily or only pop/rock music listeners that preferred systems like Audio Note UK, Devore, Harbeth, etc.

 

[Keith_W]

Just curious do you feel this improvement in clarity by minimizing phase distortion also applies to rock/pop music? There is a thread on another forum started by a mastering engineer that says "audiophiles don't really want neutral," when discussing it with people in that thread I would say a good 80-90% were heavily or only pop/rock music listeners that preferred systems like Audio Note UK, Devore, Harbeth, etc.

I don't listen to pop music. Classical only. But as is said on ASR - a good speaker is a good speaker, it does not matter what music you throw at it. I don't think my speakers are good speakers, god knows what the directivity is and I know that distortion in the tweeters happens early and is pretty high. But they are certainly interesting speakers and quite fun to take measurements of - because of the different behaviour of each driver.

I listened to Amused to Death tonight. For the first time, the barking dog is all the way to the right. I should have experimented with BACCH on/off to see how much of it was my DSP, and how much of it was BACCH. I'll try that tomorrow.

 

[Keith_W]

Now that I have exhausted everything I know about DSP on the system, I am shifting focus to improving usability of my system. The biggest issue with the system is latency, and there is a tonne of it.

The only way I can think of measuring latency is to take a video of me pressing "play", then timing how long it takes for sound to come out of the speakers. The result: ten seconds!

The reason why it takes so long is because:

- I use BubbleUPNP on my Android as my control point. BubbleUPNP sends a command to JRiver, which then fetches the stream from Tidal. This step alone takes 5 seconds between pressing "play" on the tablet and the stream to be loaded into JRiver.
- The stream then goes through a string of VST's in JRiver before it goes into Acourate Convolver. Having JRiver and Acourate Convolver side by side, it seems pretty quick for the stream to appear on JRiver, and dancing bars to appear in Acourate Convolver. Definitely less than a second.
- The output from Acourate Convolver then goes into VB-Matrix, and is then sent to two DAC's. I have no way the latency here.

So I reviewed every possible setting that might increase latency:

- Increasing the sample rate from 48kHz to 192kHz whilst keeping the tap count the same. In theory, this should bring FIR filter latency down from (65535/2*48000) 683ms to (65535/2*192000) 171ms.
- Reducing the chunk size in Acourate Convolver from 32768 to 2048 whilst listening for glitches.
- Removing all the VST's in the JRiver signal chain
- Remove VB-Matrix and getting Acourate Convolver to output directly to the DAC.
- Removed "buffer to memory" setting in JRiver
- Reduced JRiver's buffer size
- Set JRiver to not play the silence before each track

Outcome: 7 second latency. Not bad, I shaved off 3 seconds but 7 seconds is still huge.

 

[Keith_W]

Then my friend suggested I try CamillaDSP because Acourate Convolver is not known for low latency. I have resisted this in the past because Camilla was virtually impossible to install. I had to download the source code, download Rust, execute some command lines, then compile the executable myself. Forget it, it's ridiculous. As it turns out, Henrik made a new version where Camilla can be downloaded as an executable.

My friend was so pleased by my decision to try Camilla again that he came around to help. It's a really good thing he did, because to get Camilla to run, you need to edit a config file. No GUI. No drop down menu. Make a single typo, and the config file will fail. Heck, it's in YML format and if you use a spacebar instead of tab, the config file will fail. Camilla has no ASIO input. To get signal into it, you need to a loopback function. So I used the loopback function on my RME. No luck, there was excessive buffer starvation even at 48kHz and music was full of glitches. So we downloaded a software cable (VAC). Same thing, it was full of glitches.

Then he said that it's much easier on Linux. So I pulled out an old Windows laptop, wiped the HDD, and we installed Linux on it. All the while, he was assuring me that modern Linux is as easy to use as Windows. Really? First problem - the DAC driver from Merging supported an older version of Debian, but not the current version. It could not find a library that it needed. So he went and found a third party library from some guy named "Andre" who maintains it and installed it. This was when I started to realize that new Linux is just as painful as old Linux. I am never comfortable downloading software from some mysterious guy on the internet, but I tolerated it because it's on my spare and normally unused laptop.

He came over at 9pm, and left my home at 3am and it still wasn't working. He came back the next day and spent another 4 hours on it.

Well, I now have Camilla on Linux working, but not on Windows. Camilla on Windows is unusable because of the constant glitches, regardless of chunk size, regardless of sampling rate. He filed a bug report because he ran out of ideas. OTOH, Camilla on Linux seemed ... okay. Timing of the latency shows that it may be a tiny bit faster than Windows despite running on a vastly less powerful PC (an ancient i7-4600U laptop CPU vs. the i9-9600 on my Windows PC).

I told him i'm not happy with the solution since I need a Windows PC (Acourate only runs on Windows) and I don't want a separate PC for playback. I would have to re-cable for the laptop whenever I want to switch from measurement to playback, pay $200 for a new JRiver for Linux license, lose access to my VST's (including my $1000 uBACCH VST) ... and all for what? Reduce latency by less than one second?

Anyway, if he can convince me that Linux will give me a better playback experience than Windows, I might go for a dual boot solution. Boot into Windows for measurement, then boot into Linux for playback. We will see.

 

[DWPress]

It sounds exceedingly painful Keith! This is what I remember from my last Linux audio build too - this distro has this library you need but not this one and finding the missing bits is it's own rabbit hole. Probably a lot easier for folks who don't need as much I/O, hosting plugins or more than transferring over some REW PEQs.

I've spent the last week revamping the gain structure of my system, adding the last of the room treatment and of course, remeasuring everything as a result. At one point I thought I had destroyed one of my precious Audax tweeters, even ordered a replacement ($$$ ) only to discover a day later I'd somehow swapped my midrange and tweeter outputs on the right channel. Once everything is ironed out I'll make my own build thread as threatened before.

The quest for the perfect sound is ever plagued by our brilliant ideas tempered by our flawed execution!

 

[Chr1]

I tip my hat to you both.

Your commitment to the cause of ultimate audio quality is beyond the pale!

(Also, when my partner calls me a hopeless nerd for my audio, I am able to tell her there's plenty of folk way more involved than me.)

 

[3ll3d00d]

The output from Acourate Convolver then goes into VB-Matrix, and is then sent to two DAC's. I have no way the latency here.

I guess you should be able to use an rtt measurement tool with and without vbmatrix in line to get the latency of that alone though seems like your problem is basically bubbleupnp (and/or the streaming service). Is there an alternative to that on Linux?

 

[ernestcarl]

... pay $200 for a new JRiver for Linux license, lose access to my VST's (including my $1000 uBACCH VST) ... and all for what? Reduce latency by less than one second?

You already own a license so re-purchasing an upgrade (ideally) for a master license should be less.

Breaking down the the sources and the exact or approximate amount of latency would make things clearer and help you prioritize.

7 seconds of total latency is really excessive. I currently don't use any additional VSTs which makes things simpler. Often, I send optical toslink stereo audio from my Linux machine/Bluetooth/FireTV/external disc player source to my Windows PC (audio input via optical to USB converter) and am able to get no noticeable or visible lip-sync delay. I've set up different settings for minimum (~15 ms) and high (~221 ms) FIR and channel delays latency for my nearfield desk setup -- a bit less (~12ms) at the rear couch listening area. Number of taps required ranges between 768 to a max of 16k taps (latter only for the subwoofer). Admittedly, the acoustics in my own room is relatively okay even with some loss of EQ resolution plus combining both IIR and FIR filters also helps.

Ex.

 

[Keith_W]

It sounds exceedingly painful Keith! This is what I remember from my last Linux audio build too - this distro has this library you need but not this one and finding the missing bits is it's own rabbit hole. Probably a lot easier for folks who don't need as much I/O, hosting plugins or more than transferring over some REW PEQs.

At the end of the Linux process, he showed me that I had only consumed 7.3GB of HDD space on my laptop. And that's including the GUI which I made him install. Without the GUI, it would have been so small that it would fit into a thumb drive.

I suppose that's the difference with Windows. Windows installs a tonne of crap that you do not need, just in case you might need it. With Windows, removing crap you don't need is a rabbit hole. With Linux, finding stuff you need is its own rabbit hole.

Your commitment to the cause of ultimate audio quality is beyond the pale!

The "sound quality" part is done. The system sounds amazing. Unfortunately, the system also has poor usability. All my optimisations so far has been to improve sound quality without compromise, but this approach has ended up compromising too many other things. Latency is severe, and it is too complex for my wife to figure out.

I don't mind flicking half a dozen switches and launching programs before I can listen to music, but it is too difficult for her. So now my focus is to improve the usability. I need to figure out how to turn components on with 12V trigger, wire up the whole system so that turning one component on automatically turns the other components on.

My dream is to integrate it with Google Home so that my wife can speak a command, and the system turns on and is ready for her to request what she wants to listen to. I doubt if this is even possible, but I will try my best to get there. She quite rightly doubts whether all this complexity was worth it. She can hear the difference between DSP and no DSP, but to her the improvement wasn't worth sacrificing usability and she has a point! She can't use the system to listen the music, so the SQ improvement is moot!

I guess you should be able to use an rtt measurement tool with and without vbmatrix in line to get the latency of that alone though seems like your problem is basically bubbleupnp (and/or the streaming service). Is there an alternative to that on Linux?

I don't know. I asked my friend whether it is possible to run Tidal on Linux, and then use screen mirroring so that Tidal on the PC is mirrored on the tablet. He said it's theoretically possible, but he warned that it may cause its own latency issues, e.g. screen refresh and laggy interface.

You already own a license so re-purchasing an upgrade (ideally) for a master license should be less.

That is true.

 

[MaxwellsEq]

This was when I started to realize that new Linux is just as painful as old Linux.

The reason there is no sound in space is because everything runs on Linux