Print

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

[mattkhan]

Hello everybody.

Is there a freeware frequency- and impulse-response measurement tool like HOLMImpulse for Mac / OS X?

Thanks in advance.

http://www.roomeqwizard.com

[jomal]

http://www.roomeqwizard.com

Hi mattkhan.

Thank you. I knew it since the very first moment. But since the REQ was already used for other purposes, why HolmImpulse was chose to generate the impulse curve?  ?

[mwillems]

At the time this guide was written, REW did not support Frequency Dependent Windowing and had some irregularities with certain low frequency measurements, so I used Holm instead.  REW now supports Frequency Dependent Windowing, and to my knowledge the irregular bass measurement issue has been resolved.  So there's no technical reason not to use REW for the whole process at this point. 

Because of the number of screenshots and text, switching over the guide would involve a major rewrite of the guide and Ive got a one year-old child these days which limits the time I can spend on A/V forums 

[jomal]

[...]Ive got a one year-old child these days which limits the time I can spend on A/V forums 

Oh, yeah! I've been there.   

[st1]

What you'll need:

3) Holm Impulse (free measurement software): http://www.holmacoustics.com/holmimpulse.php
4) Room EQ Wizard (free measurement and automated room correction software): http://www.hometheatershack.com/roomeq/
  

REW linux version installed like expected.

for Holm impulse, I installed WINE with these instructions:
http://www.tecmint.com/install-wine-on-ubuntu-and-linux-mint/

holm installation msi file requires in wine  installation for msi files:

https://wiki.winehq.org/FAQ#How_do_I_install.2Frun_a_MSI_file.3F

I run the " wine start whatever.msi "    where  whatever is   HOLMImpulse-1.4.2.0

It installs fine and program is to be found in ubuntu 14.04 menu,  but no holm impuse start and no error message.
Then in ubuntu 15.10 comes following error message after start of holm msi file installation.

..... wine start HOLMImpulse-1.4.2.0.msi
bring following

fixme:exec:SHELL_execute flags ignored: 0x00000100
"user-at@"machine-nuc":~/Documents/Holm$ fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:mscoree:get_runtime_info unsupported startup flags 6
err:mscoree:CLRRuntimeInfo_GetRuntimeDirectory error reading registry key for installroot
err:msi:ITERATE_Actions Execution halted, action L"VSDCA_VsdLaunchConditions" returned 1603

any idea how to fix it or can it be fixed at all ?  

[ my plan is to use following:
Intel NUC with linux 15.10
jriver 21 linux as music source
REW linux for speaker & element measurements
HOLM impulse as more accurate measurement sw  (like guided earlier) but in linux wine mode
 umik-1 usb mic

... kind of simplified way of having linux os and being all the time in digital domain @96Khz
there might be better or more simple ways, but I prefer the cheap dcx2496 in use]

And big thanks for the guidance article and ideas !

edit:   ARTA for wine installation went ok

[mattkhan]

REW can do basically everything Holm can these days, is actively developed and works on Linux. I would just use REW if I were you.

[st1]

ok then trialling will continue with linux rew measurements and hopefully accurate enough for speaker element modeling with  gated FRD file measurements.

[mwillems]

ok then trialling will continue with linux rew measurements and hopefully accurate enough for speaker element modeling with  gated FRD file measurements.

REW should be just fine, and in a linux environment is preferable (as mattkhan noted). 

[mattkhan]

the latest REW beta now has a built in option to provide accurate relative phase data when using a USB mic, details in http://www.hometheatershack.com/forums/rew-forum/76226-umik-1-timing-reference-phase-4.html#post1405506 but basically it lets you use another tweeter as a fixed reference point to measure against.

[mwillems]

the latest REW beta now has a built in option to provide accurate relative phase data when using a USB mic, details in http://www.hometheatershack.com/forums/rew-forum/76226-umik-1-timing-reference-phase-4.html#post1405506 but basically it lets you use another tweeter as a fixed reference point to measure against.

That's fantastic!

[iScream]

Thank you so much for this guide.  Exactly what I needed for the 3-way active plus sub(s) setup I'm trying to build with MC 21 at the heart.

Right now I have a couple new subwoofers I built crossed over at 90Hz to set of tower speakers.  This weekend I'll be inserting a pair of mid bass modules I just built and adjusting/creating crossovers to run them from ~70Hz to ~400Hz.

I know how to do that with the PEQ and I have REW up and running through JRiver with my Dayton USB microphone.

I would like to create FIR filters with rePhase for my crossovers.  But I'm a little confused as to whether or not I will still be able to stream something like Spotify through Media Center if I'm using convolution for my crossovers, rather than PEQ. 

Have I misunderstood something I've read or is there a limitation with that?

Thanks,
Chris

[mwillems]

Thank you so much for this guide.  Exactly what I needed for the 3-way active plus sub(s) setup I'm trying to build with MC 21 at the heart.

Right now I have a couple new subwoofers I built crossed over at 90Hz to set of tower speakers.  This weekend I'll be inserting a pair of mid bass modules I just built and adjusting/creating crossovers to run them from ~70Hz to ~400Hz.

I know how to do that with the PEQ and I have REW up and running through JRiver with my Dayton USB microphone.

I would like to create FIR filters with rePhase for my crossovers.  But I'm a little confused as to whether or not I will still be able to stream something like Spotify through Media Center if I'm using convolution for my crossovers, rather than PEQ. 

Have I misunderstood something I've read or is there a limitation with that?

Thanks,
Chris

Convolution should work fine for spotify and other streaming audio; where it can fall down is with streaming video or video games.  Specifically, any application where the sound needs to be synced to a visual requires a relatively low latency audio chain.  Convolution can add quite significant latency, but you can control the amount of latency by limiting the number of taps used to make the filter (which in turn limits the utility of the filter, but that's the tradeoff).  It's really a "test and see" kind of thing as some audio hardware is natively lower latency than others, and some displays have video latency of their own, etc.    If you're just using the machine for audio reproduction (As opposed to video playback, gaming, or live audio) the latency of the output chain is irrelevant and feel free to convolve til the cows come home 

[iScream]

Convolution should work fine for spotify and other streaming audio; where it can fall down is with streaming video or video games.  Specifically, any application where the sound needs to be synced to a visual requires a relatively low latency audio chain.  Convolution can add quite significant latency, but you can control the amount of latency by limiting the number of taps used to make the filter (which in turn limits the utility of the filter, but that's the tradeoff).  It's really a "test and see" kind of thing as some audio hardware is natively lower latency than others, and some displays have video latency of their own, etc.    If you're just using the machine for audio reproduction (As opposed to video playback, gaming, or live audio) the latency of the output chain is irrelevant and feel free to convolve til the cows come home 

Thank you.  My current project is stereo music only.  I'm really interested in hearing how it sounds with crossovers that don't shift phase and some phase correction.

-Chris

[mwillems]

Thank you.  My current project is stereo music only.  I'm really interested in hearing how it sounds with crossovers that don't shift phase and some phase correction.

-Chris

Sometimes correcting the phase resolves frequency ripples and that can make a big difference, but if you already have a crossover that sums perfectly flat in the frequency domain you may not be too impressed with the result.  My active speakers crossover at 860Hz with an LR4, and they sum flat in the crossover region.  A friend and I did an ABX of the speakers with and without phase linearization on the crossover (no change in frequency response, just phase correction) and we couldn't hear the difference reliably on axis.  It can help with dispersion/lobing off axis in some setups, though, which would be audible, and it's a "motherhood and apple pie" type change (it may not be clearly audibly better, but it is definitely measurably better and free to do).  I still leave the linearization on with my system even if I can't reliably hear it  

FWIW The only "pure" phase correction that I can reliably hear is unwrapping some of the phase shift introduced by the bass reflex in my speakers.  It's a very low port tuning (27Hz), and unwrapping some of the phase shift resulted in noticeably tighter, cleaner sounding bass.  That one I can ID with certain sample tracks 100% of the time.

[Guybrush]

I'd really like to follow this tutorial and do speaker correction for my system. With three young'uns running around the house, it will be difficult to find a good block of time without significant background noise in which to do it. So, since I'm new to this, my question is how much of a sound experience difference is it before and after speaker correction? I'm sure I'll hear the difference, but will my wife (relatively non-discerning ears)? Basically, is it night and day, or a fine tuning that only an audiophile will pick up on? I know that's highly subjective and dependent on speakers and room correction needed, etc., but I'm interested in opinions.

[mwillems]

I'd really like to follow this tutorial and do speaker correction for my system. With three young'uns running around the house, it will be difficult to find a good block of time without significant background noise in which to do it. So, since I'm new to this, my question is how much of a sound experience difference is it before and after speaker correction? I'm sure I'll hear the difference, but will my wife (relatively non-discerning ears)? Basically, is it night and day, or a fine tuning that only an audiophile will pick up on? I know that's highly subjective and dependent on speakers and room correction needed, etc., but I'm interested in opinions.

I'm sorry to give a bad answer but it will really depend on your speakers and your room.  It can be night and day, or it can be more subtle.  If your speaker response isn't particularly flat for example, it can make a really big difference.  If your speakers are a pair of TAD's that are ruler flat from DC to daylight you won't get as much out of the process (if anything).  An example I often trot out is a speaker with an in band resonance.  So I have a "full range" 3 inch driver in some TV speakers I built.  The driver is pretty flat from 150Hz to 10KHz, but the cone is aluminium and has a ridiculous resonance at 15KHz.  That wouldn't normally be a huge issue (I can't hear very well up there) except for the fact that it's a 15dB or so resonance!  So that's loud enough to turn some heads at the fundamental, and loud enough to contribute undertones and resonances down into the rest of the band.  So notching that resonance out dramatically improved the sound of those speakers.  It was obvious to everyone including my wife who, to be fair, has a musical background, but doesn't pay much attention to my speaker tweaking.

So it will depend on how "untamed" your speakers are at the moment.  You can look up (or measure) how flat your speakers are and try to decide if you think it's worth your time to go the rest of the way.

[Guybrush]

I'm sorry to give a bad answer but it will really depend on your speakers and your room.  It can be night and day, or it can be more subtle.  If your speaker response isn't particularly flat for example, it can make a really big difference.  If your speakers are a pair of TAD's that are ruler flat from DC to daylight you won't get as much out of the process (if anything).  An example I often trot out is a speaker with an in band resonance.  So I have a "full range" 3 inch driver in some TV speakers I built.  The driver is pretty flat from 150Hz to 10KHz, but the cone is aluminium and has a ridiculous resonance at 15KHz.  That wouldn't normally be a huge issue (I can't hear very well up there) except for the fact that it's a 15dB or so resonance!  So that's loud enough to turn some heads at the fundamental, and loud enough to contribute undertones and resonances down into the rest of the band.  So notching that resonance out dramatically improved the sound of those speakers.  It was obvious to everyone including my wife who, to be fair, has a musical background, but doesn't pay much attention to my speaker tweaking.

So it will depend on how "untamed" your speakers are at the moment.  You can look up (or measure) how flat your speakers are and try to decide if you think it's worth your time to go the rest of the way.

I appreciate your reply. Makes sense. What I have done so far is measure reference level (with my phone) using the volume calibration. However, my rear speakers, although closer to me, are quieter than the fronts no matter how much I increase their gain. I've tried from 5dB to 20dB gain on the rears in room correction and it doesn't change the reading on my phone SPL at a given volume. Any clues why that would be?

[mwillems]

I appreciate your reply. Makes sense. What I have done so far is measure reference level (with my phone) using the volume calibration. However, my rear speakers, although closer to me, are quieter than the fronts no matter how much I increase their gain. I've tried from 5dB to 20dB gain on the rears in room correction and it doesn't change the reading on my phone SPL at a given volume. Any clues why that would be?

Where are you adding the gain?  If you're adding it in JRiver you can't really raise the absolute level of the rears, you can only raise their level relative to the fronts.  Put another way, digital audio is already as loud as it can be so adding gain to one channel digitally can only work by reducing gain to another channel, but will have no effect on the measured volume.  You can attenuate in digital but you can't really boost.  You'll need to turn up the amp feeding them if you want them to be louder in absolute terms. 

[audyart]

 
 Hello,

 Thanks for the tutorial in first page.
 One major objection i could have is the fact that a phase linéarisation can't target around a value sutch as 60° unless it means temporal distorsion:
       

       see what does a constant 40° on the shape of a square signal :

     

  so the target must be 0° ( K. 360° for a positive impulse.)

  ( apology for poor english) 

   cdt

[mwillems]

I'm sorry, but I don't understand what you're trying to communicate.  Where is there a 60 degree target?  And then you mention a 40 degree change?  I don't follow.

The rise in phase in the picture you linked is caused by the sealed box, and lienarizing low end phase rises caused by impedance peaks tends to be fruitless.  Linearizing that particular rise, for example, produced very odd sounding results indeed.

[audyart]

I'm sorry, but I don't understand what you're trying to communicate.  Where is there a 60 degree target?   

    here:

                     

  I showed the effect of a 40° average target on a square wave, a 60° is still worse.

[mwillems]

I understand now.  I think we might have to agree to disagree about this point.  I don't think absolute phase discontinuity has been shown to be audible, only relative phase discontinuity.  Put another way, group delay is potentially audible (and has been proven to be audible), plain old delay not so much. 

That's the natural phase response fo the speaker; I've had very poor results attempting to re-center the entire phase curve to a different average.  With RePhase, in any case, a lighter touch with phase manipulation is to be preferred, especially for only potentially audible benefits.

[audyart]

I understand now.  I think we might have to agree to disagree about this point. 

  I agree about our desgreement.
   Bohdan Raczynski discribes here the objective and subjective attributes of a (true) linear-phase Loudspeaker
   that can be achived using rePhase in JRiver,  the way i do. 

       http://www.linkwitzlab.com/Attributes_Of_Linear_Phase_Loudspeakers.pdf

 

[mattkhan]

FWIW REW 5.17 beta 12 (http://www.roomeqwizard.com/beta.html) now has the ability to export filters in a format that rephase can import so you can measure in REW, use it to suggest filters for you and then copy that into rephase for further tweaking. You need the latest rephase as well.

[rknox]

I have installed the Id software on a NUC and am using this as an inconspicuous renderer for my living room system.   With that now in place, I am interested in mwillems' approach to speaker/room equalization.    However, I don't believe the Id allows one to install additional software.  My initial plan had been to take advantage of the now full functionality of the REW package running on Linux to conduct the room equalizing procedure on my Id/NUC.  Is installing REW into the Id environment at all possible?

Assuming that it is not an option, I was thinking an alternative approach would be to use a Windows based setup to conduct the testing and to create the appropriate parametric filters.   I believe mwillems wrote that that the filter parameters could then be transferred to the mc DSP parametric equalizer.    Presumably this would result in a room corrected version of the id?   I guess it assumes that the audio characteristics of mc in Linux are identical to those under Windows ...   Thoughts on this or other approaches?

Thanks,

[mwillems]

I have installed the Id software on a NUC and am using this as an inconspicuous renderer for my living room system.   With that now in place, I am interested in mwillems' approach to speaker/room equalization.    However, I don't believe the Id allows one to install additional software.  My initial plan had been to take advantage of the now full functionality of the REW package running on Linux to conduct the room equalizing procedure on my Id/NUC.  Is installing REW into the Id environment at all possible?

I can't comment on how easy or hard it would be to install REW in an Id, environment, but it's easy enough to isntall on a normal Linux environment.

Assuming that it is not an option, I was thinking an alternative approach would be to use a Windows based setup to conduct the testing and to create the appropriate parametric filters.   I believe mwillems wrote that that the filter parameters could then be transferred to the mc DSP parametric equalizer.    Presumably this would result in a room corrected version of the id?   I guess it assumes that the audio characteristics of mc in Linux are identical to those under Windows ...   Thoughts on this or other approaches?

That's a safe approach.  Barring some unexpected filtering in the Linux audio stack (which shouldn't be an issue with the Id), you can easily measure on Windows and just copy the filters across.  I've done this on several occasions with good success (taken a windows laptop to a friend's house to measure their system and hand copied the filters across to their Linux computer).  In one case I was planning to convert an existing windows HTPC with equalization already dialed-in to Linux, and I just exported the existing library, imported the library on the Linux side, and all my EQ came across intact and the system measured identically afterwards.

[PGibby]

First off, thank you for this thread. I'm new to DRC, so this has been a huge help.

I first downloaded Dirac and am currently using it during the trial period, and I've got to say, the results are fantastic. Unfortunately, Dirac is expensive, so I want to try to get Dirac-like results, but with freeware (and extra work).

My system consists of:

Speakers: Meadowlark Nighthawks
Sub: DIY Rythmik DS1501
Amp: Audio Research VS-55
Preamp: Audio Research LS2
Dac: Sonic Frontiers SFD-1 Mk2
Source: HTPC running win10
Other: Jriver20, calibrated usb mic, REW

So, if anyone has any advice on my strategy below, please chime in:

1) Measure left and right channels independently in REW. Move mic around to 5 or 6 spots in the general "listening area" like Dirac suggests. Average those results for each channel independently, and have REW suggest EQ. Input that EQ into JRiver's PEQ manually.
2) Loop all audio through JRiver, and run the same 5 or 6 measurements per each channel, and average those per each channel. Export that into rePhase.
3) Play around in rePhase, do some FIR filtering there. Export those results and import them into JRiver's convolution engine.

Does this sound like I'm on the right path?

When I first got the measurement mic, I did 1 sweep with both channels in the listening position, had REW suggest filters, then exported those into the convolution engine in JRiver. The results...where not so good. Really flat, no life. So the method above may produce some better results? What do you all think?

[mwillems]

First off, thank you for this thread. I'm new to DRC, so this has been a huge help.

I first downloaded Dirac and am currently using it during the trial period, and I've got to say, the results are fantastic. Unfortunately, Dirac is expensive, so I want to try to get Dirac-like results, but with freeware (and extra work).

My system consists of:

Speakers: Meadowlark Nighthawks
Sub: DIY Rythmik DS1501
Amp: Audio Research VS-55
Preamp: Audio Research LS2
Dac: Sonic Frontiers SFD-1 Mk2
Source: HTPC running win10
Other: Jriver20, calibrated usb mic, REW

So, if anyone has any advice on my strategy below, please chime in:

1) Measure left and right channels independently in REW. Move mic around to 5 or 6 spots in the general "listening area" like Dirac suggests. Average those results for each channel independently, and have REW suggest EQ. Input that EQ into JRiver's PEQ manually.
2) Loop all audio through JRiver, and run the same 5 or 6 measurements per each channel, and average those per each channel. Export that into rePhase.
3) Play around in rePhase, do some FIR filtering there. Export those results and import them into JRiver's convolution engine.

Does this sound like I'm on the right path?

When I first got the measurement mic, I did 1 sweep with both channels in the listening position, had REW suggest filters, then exported those into the convolution engine in JRiver. The results...where not so good. Really flat, no life. So the method above may produce some better results? What do you all think?

My advice (laid out at length above) is not to measure at the listening position at all during the first phase, except as a check on how the correction is going.  My advice is to measure the speakers at various distances on axis, average those, and then feed that result into REW to generate the correction.  Others may disagree with the approach, but I have consistently gotten much better and much more reproducible results following the methodology laid out in this thread than any combination of listening position measurements.  You can see my rationale laid out at length in the opening posts.

Once you've corrected your speakers, you can use listening position measurements to try and dial in room correction, but (as described above) that's not an automated process.

At this point you should be safe to use REW to measure instead of HOLM as REW now has Frequency Dependent Windowing, but the screencaps above will obviously not help with that part of the process :-)

[PGibby]

My advice (laid out at length above) is not to measure at the listening position at all during the first phase, except as a check on how the correction is going.  My advice is to measure the speakers at various distances on axis, average those, and then feed that result into REW to generate the correction.  Others may disagree with the approach, but I have consistently gotten much better and much more reproducible results following the methodology laid out in this thread than any combination of listening position measurements.  You can see my rationale laid out at length in the opening posts.

Once you've corrected your speakers, you can use listening position measurements to try and dial in room correction, but (as described above) that's not an automated process.

At this point you should be safe to use REW to measure instead of HOLM as REW now has Frequency Dependent Windowing, but the screencaps above will obviously not help with that part of the process :-)

Thank you. You've been a great help, and your first post on this thread got me to buy a calibrated mic.

I think I'm going to try something a little different (and it may not work), but I'll give it a try as my time without kids running around the listening area is very limited.

I'm going to do as you suggested, with "speaker" correction first. Then, with that correction applied in the PEQ of JRiver, then move into the "room correction" part using DRC Designer routing audio with the WDM driver (so the PEQ is applied). It looks a little more automated than RePhase. It also has easy house curve adjustments as well.

I'll let everyone know how it goes.

[mattkhan]

I'm going to do as you suggested, with "speaker" correction first. Then, with that correction applied in the PEQ of JRiver, then move into the "room correction" part using DRC Designer routing audio with the WDM driver (so the PEQ is applied). It looks a little more automated than RePhase. It also has easy house curve adjustments as well.

are you aware that the latest REW can export filters in a format that rephase understands? i.e. process can be as simple as; measure in REW, suggest filters, export to xml, load into rephase, tweak phase, export as impulse, load into jriver, enjoy!

[PGibby]

I've ended up trying a couple different methods, and this one worked the best for me:

Measured in REW each channel and corrected for 200hz and lower. Put those filters in PEQ in JRiver.
Fire up DRC Designer, set JRiver as your output now (so the PEQ adjustments take effect), and run the sweeps there. Let it do its thing. It'll export FIR filter wav files of your sampling rate choices and whatever house curve you aim for. Pick out whatever one sounds best, then if you want to go a step further, you can make a custom one. My DAC is an oldie but a goodie (Sonic Frontiers), so it only handles 44.1 and 48khz. Simply make a config file to tell it what filter to use based off of the sample rate of the source file.

Works VERY well, and I'd say I got very close to the results I got with DIRAC.

I tried following mwillems advice, but I had a few problems:

1) I tried measuring the speakers as best i could without room interaction, and with the design of my house, I don't think I was able to get a location where I wasn't finding some. I could tell because I would move the speaker a little (like in the dead center of my biggest room), and measure it. Then, move it a little with the same mic distance, and get a different result.

2) Time...i just didn't have the time to run through it all as my progress was slow.

I went for the easy button with REW correcting below 200hz, then used DRC Designer for the rest...and it turned out, in my case, really well.

[mk9pa]

MWillems, thanks for the outstanding guide.

I am working on getting DRC working under MC22 on a Raspberry Pi 3 on Raspbian.

Although your recommendation is to use the Parametric Equalizer for frequency equalization, I started with Convolution because it was a quicker path to get my feet wet.  I am using REW to generate filter impulse files and set up a cfg file for MC22.  It works but for all but 44.1 sample rates the Pi's CPU is overloaded.  This must be due to the REW impulse file's 128k sample size, which causes quite a large computational load for the convolution.  This parameter does not seem to be adjustable.  With the Convolution window's "Performance" number (x real time), and the % CPU taken by the mediacenter22 executable while running:

• 16/44.1 source: 2.9, 50%
• 24/96 source: 1.4, 100%
• 24/88.2 source: 2.0, 80%

The 24/96 source has obvious serious distortion, the 24/88 source has frequent crackles/tearing. The 16/44 source sounds fine.

OK, so maybe Parametric Equalizer is less CPU intensive.  The same REW filters can be written out as text files with the filter specs.  This particular set has 13 filters for the right channel and 19 for the left, i.e. total 32 (this was a really quick try, nothing thorough here yet).  Playing a 24/88 source without any processing, average CPU utilization of mediacenter22 is about 42%.  Adding in all 32 filters, it climbs to around 70%, is highly variable, and produces occasional crackling sounds.  24/96 source with filters ranges around 60-90% and has obvious crackling.  16/44 source produces occasional crackling and runs around 30-50% with occasional peaks to 80% that I see.

There appears to be a general increase in average CPU utilization with this many filters, but what appears to happen also is that the variation in CPU usage increases.  In any case, there doesn't seem to be much headroom available with either approach.  I note that somewhere I saw that SSE instructions were used for Intel processors which would help a lot for this; ARM processors have something similar but different, and although the ARM processor in the RPi 3 B is 64-bit, having the OS and compilers fully take advantage of that may not be fully baked yet.

Any suggestions for attacking this problem on the Pi 3?

[mattkhan]

Try using rephrase to generate the filters instead as you can use it to reduce the length of the generated filter. You can export from rew and import into rephrase btw. This would let you use the same filter set but with different frequency resolutions, ie shorter filters have a coarser resolution, to see how you can trade off precision vs CPU.

Alternatively you can review the filters themselves to remove unnecessary ones, perhaps you are trying to do too much. You can also change the targets in rew, particularly the flatness target and the frequency range, to get it to do less in the first place.

[mwillems]

Matt's advice is good; fewer taps or fewer filters are the most likely answer here.  You quote a cpu percentage, but it's unclear what the source of that percentage is.  Many Linux performance monitoring tools display each processor as a separate pool so max usage on a pi would be 400% not 100%, so I'm not sure if MC is using 50% of one thread or 50% of total cpu available.  If you could clarify and also indicate the load average, I might have an idea or two.

Three things to try that are pi-specific to squeeze out a little performance if you haven't already:

1) Try setting the pi's cpu governor to performance.  That might help reduce drop outs in the more hopeful cases, as latency tends to spike when the processors try to downclock, which they will do periodically with the default pi cpu governor (which is either powersave or ondemand depending on the raspbian version).  You could also try overclocking it, but the foundation does not recommend it with a pi 3.

2) Make sure your powersupply is adequate; the pi 3 needs more power than prior pis and the foundation recommends a 2.5A minimum power supply for the pi 3 for just the board.  If you've added usb peripherals or daughterboards/hats you need yet more power, sometimes as much as an amp more.  Lack of power can manifest as instability, but it can also manifest as CPU throttling or erratic performance.  If you've got the pi hooked up to a monitor it will signal this to you by floating a multicolored square in the upper right hand corner, but if you're headless you'd never know.  So (if you're using a 1.5 or 2 A power supply) find a good 3 amp power supply, and try powering any USB peripherals using a powered USB hub and see if that helps at all.

3) If you've got the pi in an enclosed case, there's also a chance it may be overheating or thermally throttling, as the pi 3 runs hotter than prior generations, and the foundation conditionally recommends a heatsink for the pi 3.  If you're running the board open air or with a fan, ignore this, but if you've got it inside a closed case consider installing a little heatsink on the processor.  You can test by polling the pi's cpu temperature while it's under load to see how hot it's getting.  Below 60C is fine, and this is definitely not your issue.  Below 70C is also probably fine, more than 70C is iffy, more than 80C is very likely to be an issue.  If temperature looks like it might be relevant you can get cute cheapy heat sinks for a few dollars.  Even the cheapy ones can make a 5 or 10C difference based on my own measurements, which could be meaningful if it's cooking. 

[mk9pa]

Yes, it makes sense to try simpler filters or shorter samples.  Regarding the performance suggestions, what I reported as CPU utilization is the utilization of the single CPU core running MC (from the "top" command).  The Raspbian release I am running (latest available) sets "ondemand" CPU governor but with a 50% up threshold, so the clock goes up when the CPU is 50% utilized.  I figure that's not bad (the default used to be 95%) and I'm keeping it there for now.  I could lower that some, or just set it to "performance" but will have to experiment with that when I have a little more time.  Power supply: I tested by bringing home a big bench supply and connecting it directly to the HiFiBerry power supply which also feeds directly into the Pi's power.  No difference.  The default supply is a 2.5 A wall wart.  I have the small heat sinks that come with the Pi 3 board installed, and am using a HiFiBerry case that has holes in sides and top. However, the DAC board sits on top of the CPU board, so air movement is reduced. I ran a system profiling app with thermometer and while playing a 24/96 file with 32 filters, it ran in the mid-50s, up to 57 C max that I see.  This must be because only one CPU is being fully utilized.

Something else I notice at the moment: I updated to MC 22.0.71 since it appeared in the JRiver repo, and now MC is using significantly less CPU on the Pi than before.  Up above I report that with convolution of a 128k sample impulse file and playing a 24/88 file MC reports it's running 2.0x realtime with 22.0.63; now it's running 3.5x and using 40% CPU instead of 80%.  Really now. That is a big difference.

But I have been stuck for the last week on an inability to run REW on the Pi.  It appears that nobody else has this problem, and I was able to run it a couple of weeks ago too, and cannot identify a reason why anything changed.  The REW app starts up fine, sends signals out to the audio output for about 1 second, then stops, and loses the connection to all its audio devices (DAC output and USB microphone input).  This happens with both the HiFiBerry board and an external USB DAC. Currently stuck trying to get that understood. Could be Java, but tried 3 versions (2 from Oracle and one OpenJDK which was very poor performance).

[trento]

At the time this guide was written, REW did not support Frequency Dependent Windowing and had some irregularities with certain low frequency measurements, so I used Holm instead.  REW now supports Frequency Dependent Windowing, and to my knowledge the irregular bass measurement issue has been resolved.  So there's no technical reason not to use REW for the whole process at this point. 

Because of the number of screenshots and text, switching over the guide would involve a major rewrite of the guide and Ive got a one year-old child these days which limits the time I can spend on A/V forums 

Hi to everyone!
This is a great guide, really, great! My starting point.
I'm new on this forum, to DRC/FIR/IIR an so on...

I've read on a tech magazine that windowing is essential for the math and filter and change a lot the results, is it true? could it be possible to have a screenshot or two about the parameters we have to change on REW to maintain the consistency with that guide?

Thanks to all contributors
Matteo

[mk9pa]

Hi Mwillems,


I have gone through a full loop of measurements, filter generation in REW, and phase linearization in rePhase, resulting in a dramatic improvement in music quality on a pair of inexpensive bookshelf speakers I am using for practice. I used just the simplest flow: one measurement per channel at a nominal listening position.  This is to get some practice with the tools and methods. It takes some gymnastics between the various tools and, in my case, OSs since MC target is a Raspberry Pi 3 B running Linux and not all tools involved are available on that platform.  Previous issue with inability to run REW on the Pi was fixed by rebuilding the Pi OS from scratch.


With that as background, I'd like to strategize a fully-developed approach to room/speaker correction.  Your method as described in this thread is one that is intuitively attractive because it decouples speaker and room, one of which (speaker) can be addressed with a constant correction no matter where they are placed.  A single measurement at listening position as I've done so far is not a good solution: I can tell that moving a few inches from the mic position changes the sound significantly.  The filter gain values REW assigned include some at -18 dB, -16.5 dB, and numerous around -9 dB, and Q values including 6 between 6.2 and 10.6, which is consistent with overfitting. These are likely due to room modes or reflections that are highly specific to placement.


An alternative approach may be to take measurements at a number of spatially diverse positions in the listening region and averaging them in some way, with the goal of producing filters with Q values in a more constrained range.


I wanted to ask whether you researched alternative approaches when developing your method.  I've found only offhand mention of taking multiple spatially-diverse measurements and combining them. I understand that close-measuring the speakers avoids a lot of the issues, but I am trying to see if at least the first-order room effects can be included in the filter generation without overfitting.

[mwillems]

I wanted to ask whether you researched alternative approaches when developing your method.  I've found only offhand mention of taking multiple spatially-diverse measurements and combining them. I understand that close-measuring the speakers avoids a lot of the issues, but I am trying to see if at least the first-order room effects can be included in the filter generation without overfitting.

I did a great deal of empirical research, by which I mean measuring at different places in my room and others' rooms, trying corrections and then remeasuring, etc.  I can say that none of those methods provided predictable results in the same way that speaker linearization did.  It's really something you'll have to trial and error your way through.  One rule of thumb I can share from my experiments is that adding boost in room correction (as opposed to speaker correction) is almost always an error as you're typically trying in vain to fill up a cancellation or room mode.  This will not work at the measuring position and will make a mess everywhere else.

My experience is also that if you haven't linearized the speakers first you will spend a lot of time chasing phantoms.  Trying to correct the interaction of two systems only one of which is fully correctible is a recipe for heartbreak IME;  correct the solveable system first (the speaker) and then work on the intractible second system (the room).  Once you've linearized your speakers, averaging the room response across the listening area is a good idea for a test, but may not work in practice.

[Manfred]

If you set the target level in REW, is it better to have it the same for the left and right speaker or using the value calculated by set target level->results for left and right speaker then differ. My left B&W 804 S needs only two filters for the left speaker where as the right speaker (near a window with curtain) needs ~20 filters.

By the way an excellent guide!

Thank you very much for your help!

[Audiofi3l]

Thank you for this great guide!

One question though, what is the best way to stitch a three way together? First tweeter and mid, and then the result of that with the woofer or something else? Do i have to use both crossovers (i have one at 250 hz and 2500 hz with my speakers) with stitching or only the obvious one? The one at 250 hz isn't obvious...

I have tried it a few times but the results of the 3 inch, foot and meter differ more then in your example and i tend to get a big peak down at the 2500 hz crossover when stitching the 3 inches...

Thanks in advance for your help!

[mwillems]

Thank you for this great guide!

One question though, what is the best way to stitch a three way together? First tweeter and mid, and then the result of that with the woofer or something else? Do i have to use both crossovers (i have one at 250 hz and 2500 hz with my speakers) with stitching or only the obvious one? The one at 250 hz isn't obvious...

I have tried it a few times but the results of the 3 inch, foot and meter differ more then in your example and i tend to get a big peak down at the 2500 hz crossover when stitching the 3 inches...

Thanks in advance for your help!

The stitching and separate measurement should ideally be done for each "way," i.e. each speaker or set of speakers playing a single band.  I'm not sure what you mean by one crossover is "obvious" but the other isn't?  Do you mean audible vs. not audible or physical spacing or something different?  In any case the order in which you stitch them shouldn't matter as your crossovers are a decade apart.

If you're getting a big null at the 2500Hz crossover that suggests that either your measurements or your speakers have poor phase alignment.  If it's a really massive null, you probably just have the polarity flipped between the two measurements, either in your microphone or in your speakers.  Try inverting the phase of one or the other of the measurements (probably easiest to do the >2500Hz measurement).

[Audiofi3l]

The stitching and separate measurement should ideally be done for each "way," i.e. each speaker or set of speakers playing a single band.  I'm not sure what you mean by one crossover is "obvious" but the other isn't?  Do you mean audible vs. not audible or physical spacing or something different?  In any case the order in which you stitch them shouldn't matter as your crossovers are a decade apart.

If you're getting a big null at the 2500Hz crossover that suggests that either your measurements or your speakers have poor phase alignment.  If it's a really massive null, you probably just have the polarity flipped between the two measurements, either in your microphone or in your speakers.  Try inverting the phase of one or the other of the measurements (probably easiest to do the >2500Hz measurement).

Thank you for the quick reply. I am relatively new to this, so propably asking the obvious questions 
By obvious i mean it was clearly visible in the measurements. The one at 250 Hz was not visible, while the 2500 one was very obvious.

I have measured the speakers as you described but i played them normally while measuring, meaning not playing single bands or so. I have attached the measurements of the left speaker (the right one is more or less the same).

If i understand correctly, i have to stitch tweeter->mid, tweeter->woofer, mid->woofer. Do i have to stitch all those together too?

[mwillems]

Thank you for the quick reply. I am relatively new to this, so propably asking the obvious questions 
By obvious i mean it was clearly visible in the measurements. The one at 250 Hz was not visible, while the 2500 one was very obvious.

I have measured the speakers as you described but i played them normally while measuring, meaning not playing single bands or so. I have attached the measurements of the left speaker (the right one is more or less the same).

If i understand correctly, i have to stitch tweeter->mid, tweeter->woofer, mid->woofer. Do i have to stitch all those together too?

No that's the wrong way around.  The goal is to create a single stitched measurement that shows the appropriate band for each speaker.  You want to stitch the mid to the tweeter, and then stitch the woofer to the results of the first stich.  Alternatively, stitch the woofer to the mid, and then stich that result to the tweeter.

So
1) M->T = MT
2) W->MW=WMT
or
1)W->M=WM
2) WM->T=WMT

[Audiofi3l]

Ok, thank you! Hopefulle one last 'dumb' question:-) do i choose just one cross-over or do i create two stitch sets each with one cross-over and stitch those two also together?

I have added a picture with my results stiched together with the as described in your example with the 2500 hz cross-over point. They are not as close together as in your example after stitching. I that a problem do you think?

[mwillems]

Ok, thank you! Hopefulle one last 'dumb' question:-) do i choose just one cross-over or do i create two stitch sets each with one cross-over and stitch those two also together?

I'm not 100% sure I understand your question; how can you stitch the measurements together at just one crossover?  The woofer mostly plays between 20Hz and 250Hz; the midrange mostly plays from 250Hz to 2500Hz; the tweeter mostly plays from 2500Hz up to wherever it stops playing.  If you tried to stich the tweeter using the 250Hz crossover you'd be including a huge band in which the tweeter isn't even playing.  The idea is to stitch the measurements to create a composite picture of what the speaker sounds like in the bands where each element is playing.

You should be stitching the measurements at the crossover point for the two measurements that you are stitching (imagine stitching a quilt together, each piece needs to be stitched at its edges).  So if you're stitching the woofer to the midrange you should use the 250Hz crossover point to stitch.  If you're stitching the midrange (or the midrange-woofer composite) to the tweeter you should be stitching at the 2500Hz crossover point. 

Does that make sense?

[Audiofi3l]

I'm not 100% sure I understand your question; how can you stitch the measurements together at just one crossover?  The woofer mostly plays between 20Hz and 250Hz; the midrange mostly plays from 250Hz to 2500Hz; the tweeter mostly plays from 2500Hz up to wherever it stops playing.  If you tried to stich the tweeter using the 250Hz crossover you'd be including a huge band in which the tweeter isn't even playing.  The idea is to stitch the measurements to create a composite picture of what the speaker sounds like in the bands where each element is playing.

You should be stitching the measurements at the crossover point for the two measurements that you are stitching (imagine stitching a quilt together, each piece needs to be stitched at its edges).  So if you're stitching the woofer to the midrange you should use the 250Hz crossover point to stitch.  If you're stitching the midrange (or the midrange-woofer composite) to the tweeter you should be stitching at the 2500Hz crossover point. 

Does that make sense?

It does make a lot of sense now. Thank you for your patience! I go for the next round now, thank you again!

[Audiofi3l]

I get an error (see picture) when i try to import the 3 inch stitches of both left and right. The other stitches from 1 foot and 1 meter just import normally. What can it be?

Doing the stitch again doesn't solve the problem...

[mwillems]

I've never seen that error before, but if I had to guess you may have stitched the measurements in the wrong order/arrangement? 

[Audiofi3l]

I've never seen that error before, but if I had to guess you may have stitched the measurements in the wrong order/arrangement?

Well, i tried starting with woofer and tweeter, but it makes no difference... Also installed the latest beta from REW, but no difference, exept it doesn't asking the C-weighted question anymore and popped-up the error instantly...

[Audiofi3l]

I have done the 3 inch measurements again and now i can import the stitches from these in REW!

And using the results... But... The main reason to start this traject was a huge overpowered standing wave at ~ 37,5 hz at the listen position. It was clearly visible at the initial measurements at this listening position.

After the closer speaker measurements as described in the manual and stitching them together and let REW average the results, there is almost no peak left at this 37,5 hz. When REW calculated the target level there is almost no correction done at this point. Listening to the result thus still has a huge problem at 37,5 hz. Other 'problems are propably fixed but overpowered by the existing boomy 37,5 hz...

Did i do something wrong, or is there another way to correct this?