Digital Room Correction

> On Thu, Jan 15, 2009 at 2:33 PM, Erik Gustavsson <cyrano@...> wrote:
>>> Hello Erik,
>>>
>>> On Wed, January 14, 2009 12:25, Erik Gustavsson wrote:
>>>> It then occurred to me that it would be pretty neat to integrate DRC
>>>> directly in the "box" and make the system completely self contained.
>>>
>>> may be that, by reducing a lot of "safety" parameters of DRC, used
>>> mainly
>>> to
>>> avoid circular convolution artifacts, you will be able to let it run on
>>> that
>>> system. By reducing them you also make the computation quicker. BTW you
>>> incur
>>> the risk of reducing the filter quality too.
>>>
>>
>> I did some tests on my Linux laptop, using ulimit to cap the virtual
>> memory size of DRC to 60MB. I took erb-44.1.drc and modified some
>> settings
>> until the whole run completed without crashing.
>
> Check out http://www.digispeaker.com it is an open source/hardware project.
> The idea is to put a CPU and amp right inside each speaker box and
> then use powerline networking to control them.
>

A very cool project!

>
> Low end embedded CPUs with FPUs...
> Freescale mpc5200 - well supported by linux
> Cirrus ep9302 - too slow for tri-amping
> NXP 3240 - new, haven't tried it, slower than mpc5200
> Freescale MX31 - faster but significantly more complex than mpc5200
> Marvell - Orion, don't call unless you have $1M in the bank
> TI - OMAP, don't call unless you have $1M in the bank
>

Thanks for the pointers.

/Erik

> Hello Erick,
>
> On Thu, January 15, 2009 20:33, Erik Gustavsson wrote:
>> The changes I made:
>>
>> BCInitWindow = 65536
>> HDMultExponent = 3
>> PTFilterLen = 32768
>> PSMultExponent = 2
>
> the various *MultExponent are the key factor for memory usage, there are
> many
> of them. The other two should make little changes. Setting the
> MultExponents
> to a value of 2 should be already on the safe side
>
>> Next I'm going to try cross-compiling DRC and see what kind of run-time
>> I
>> get on the AVR32. Perhaps that will be a bigger problem than the memory
>> issue.
>
> Yep. Lot of floating point math within DRC. Without an FPU is going to
> take
> forever...
>

You are probably right about that.

It seems my options are:

1) Give up and run the filter generation on a PC.
2) Ditch the AVR32 and switch to a processor with FPU.
   Cirrus EP3902 looks quite nice from a quick glance,
   DIY friendly QFP package and all...
3) Offload the heavy calculations from DRC onto the same DSP
   hardware that will run the realtime convolution. Likely
   an ADI SHARC floating point DSP processor + an FPGA.

Clearly, the coolness factor (and amount of work) goes up
exponentially as we go down the list...  :-)

/Erik

On Fri, Jan 16, 2009 at 4:28 AM, Erik Gustavsson <cyrano@...> wrote:
>> Hello Erick,
>>
>> On Thu, January 15, 2009 20:33, Erik Gustavsson wrote:
>>> The changes I made:
>>>
>>> BCInitWindow = 65536
>>> HDMultExponent = 3
>>> PTFilterLen = 32768
>>> PSMultExponent = 2
>>
>> the various *MultExponent are the key factor for memory usage, there are
>> many
>> of them. The other two should make little changes. Setting the
>> MultExponents
>> to a value of 2 should be already on the safe side
>>
>>> Next I'm going to try cross-compiling DRC and see what kind of run-time
>>> I
>>> get on the AVR32. Perhaps that will be a bigger problem than the memory
>>> issue.
>>
>> Yep. Lot of floating point math within DRC. Without an FPU is going to
>> take
>> forever...
>>
>
> You are probably right about that.
>
> It seems my options are:
>
> 1) Give up and run the filter generation on a PC.
> 2) Ditch the AVR32 and switch to a processor with FPU.
>   Cirrus EP3902 looks quite nice from a quick glance,
>   DIY friendly QFP package and all...

The EP9302 has a non-standard FPU, the Maverick. It has 'issues' like
not always doing the math right.
The LPC3240 is in the same price range and has a standard VFP FPU.

> 3) Offload the heavy calculations from DRC onto the same DSP
>   hardware that will run the realtime convolution. Likely
>   an ADI SHARC floating point DSP processor + an FPGA.

We are running the realtime convolution on the mpc5200. mpc5200 is
0.5GF. That is plenty of FPU. It can do three simultaneous 131K tap
filters with room to spare.

If you really want to go crazy, the Efika supports AGP cards via a
riser available at Directron.
Put a GPU into the Efika board.
http://koonlab.com/MultiAmpForEveryone/FIR_HDMI_AVAMP.html
Koon runs a two million tap filter.

Another strategy is to just use an Intel Atom motherboard. Most Atom
motherboards have 192/24 DACs on their HDA output. Koon used the HDMI
output from the GPU to get the audio out.

GPU totally blows away any reasonable DSP/FPGA solution. And you can
upgrade it, just swap out the video card.

The audio part of the project is not causing us trouble. The trouble
is in the networking and power supply areas. For example we wasted a
lot of time on 802.11 before we gave up. No one would sell us chips or
give us programming specs. 802.11 is in the "have a million in the
bank before you call" group.


>
> Clearly, the coolness factor (and amount of work) goes up
> exponentially as we go down the list...  :-)
>
> /Erik
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Drc-fir-users mailing list
> Drc-fir-users@...
> https://lists.sourceforge.net/lists/listinfo/drc-fir-users
>



-- 
Jon Smirl
jonsmirl@...

I guess it depends what people are building, but for a one off device I 
think it's hard to beat the Intel D201GLY

eg: under £40 from
http://www.google.co.uk/products/catalog?q=D201GLY&oe=utf-8&cid=192037039700504458#ps-sellers

The Atom looks interesting but when I last looked many of the 
motherboard were being saddled with a power hungry supporting chipset 
which seemed to defeat a lot of the point of having a nice low power 
processor (durr)

Quite interested to hear more about anyone's venture with proper 
embedded processors though. No help for this project, but I'm doing some 
stuff with the PC Engines Alix boards and they are really very good.

Good luck all

Ed W

Hello Nicola,

On Fri, January 16, 2009 10:45, nicola.prada@... wrote:
> c) If is not possible to record the reference channel with rec_imp, do you
> think it is so important to use the reference channel or is it something only
> for paranoid people? Are the filters different if created with or without the
> reference channel?

the second one. The reference channel makes sense only with low quality DACs
or when you need perfect time references for the impulse response.

> d) How can I be sure the signal is not clipping without being able to see it
> graphically? Is there some kind of control built into rec_imp?

Just use a conservative approach. The soundcard never is the limit factor WRT
noise. Even if you record at, say, -20 dBFS you still have a wide margin WRT
to the mic and room noise.

Bye,

-- 
	Denis Sbragion
	InfoTecna
	Tel: +39 0362 805396, Fax: +39 0362 805404
	URL: http://www.infotecna.it

Author of that utility here:

> a) Do you believe rec_imp is superior to Audacity for this task?

Nope - it least not in performance

All it does is automate the recording and inversion process.  If you 
examine the command line params though it can be useful for a couple of 
things though - I use it to put out tones at specific freqs, or sweep a 
narrow range and open the results in Audacity, etc (check specific problems)
 
> b) Is there a way to record with rec_imp both the channels with the 
> reference channel without having to manually disconnect the cables 
> from my external DAC?
>  
> Something like:
>  
> Play this mono sweep on SPDIF left channel only + Analog 2 OUT and 
> record both from Analog 1 IN and Analog 2 IN

I didn't read this closely enough, but yes you set two channels for 
output and two channels for input.  It defaults to something sensible 
(not using the freeback channel from memory...)


> c) If is not possible to record the reference channel with rec_imp, do 
> you think it is so important to use the reference channel or is it 
> something only for paranoid people? Are the filters different if 
> created with or without the reference channel?

Dunno - my soundcard doesn't require a reference and also if you are 
using certain audio output methods (alsa/jack) it's sample perfect 
start/stop so you can use it as an audio tape measure also!

Denis just said not, but I have no opinion...
 
> d) How can I be sure the signal is not clipping without being able to 
> see it graphically? Is there some kind of control built into rec_imp?

If you examine the output you will see that it spits out peak levels 
both in the recording and in the inverted file.  The main one is the 
peak level in the recording.

Note some sound cards like you to leave a chunk of headroom on the mic 
input for various reasons.  Quality cards can often go near 0dB without 
problems.  It is safer to leave a touch of headroom, but on the other 
hand lower quality cards often only have 40dB of dynamic rance on the 
mic input so some optimisation is a good idea

I normally do a quick 5 second sweep to set levels and then run my real 
sweep



Good luck

Ed W
>

Hi Nicola,

On Fri, Jan 16, 2009 at 10:45:05AM +0100, nicola.prada@... wrote:
> b) Is there a way to record with rec_imp both the channels with the reference channel without having to manually disconnect the cables from my external DAC? 

I'm using rec_imp as follows (on a Linux system) and find it very convenient:

- Before compiling rec_imp I have edited its 'Makefile', and added the
  option '-DKEEP_TEMP_FILES' to the 'CFLAGS' setting (if you don't have a
  Pentium 4 you must edit the -march setting anyway).
  Then 'rec_imp' doesn't remove the recorded signal.

- For the measurement of both stereo channels I use the following script
  (using two different devices for playback and recording):

===========   doit  ==================================================
#!/bin/bash
export TIME=$1
export RESDIR=$2
rm -f /tmp/drc*
sleep 5
rec_imp LeftStl.pcm 44100 15 20000 ${TIME}  0:2 0:0
mv /tmp/drcrec* LEFTdrcrec
rec_imp RightStl.pcm 44100 15 20000 ${TIME}  1:2 0:0 
mv /tmp/drcrec* RIGHTdrcrec

sox -M -t raw -r 44100 -c1 -fl LEFTdrcrec -t raw -r 44100 -c1 -fl RIGHTdrcrec -r44100 -c2 -sw leftrightrec.wav
#rm -f LEFTdrcrec RIGHTdrcrec 
sox -M -t raw -r 44100 -c1 -fl LeftStl.pcm -t raw -r 44100 -c1 -fl RightStl.pcm -r44100 -c2 -sw leftrightResponse.wav

mkdir ${RESDIR}
mv LeftStl.pcm RightStl.pcm leftrightrec.wav leftrightResponse.wav ${RESDIR}
=====================================================================
  
  I first call it like 'doit 5 resultdir' with 5 second sweeps, and check with 
  audacity or something else if it looks good:
    audacity resultdir/leftrightrec.wav
    audacity resultdir/leftrightResponse.wav
  (for the latter use 'Normalize' effect and zoom to the interesting tiny
  bit in the middle)
  If it looks fine I redo it with longer sweeps 'doit 60 resultdir',
  the 'sleep' command in the beginning give me time to leave the room for
  that.




And here I have a question/request about rec_imp myself:

It would be nice if rec_imp could be extended to take a filter file
(say, computed by drc) as optional argument. When given then this filter
should be applied to the generated sweep before it is played.
This way it would be very convenient to do some test measurement with
correction turned on. 
(I guess that everything which is needed for this is already in the code 
rec_imp. But the expert could probably implement this much faster than I
could figure it out.)

Best regards,
  Frank

Hi

> I'm using rec_imp as follows (on a Linux system) and find it very convenient:
>
> - Before compiling rec_imp I have edited its 'Makefile', and added the
>   option '-DKEEP_TEMP_FILES' to the 'CFLAGS' setting (if you don't have a
>   

Hey, cool feature - had forgotten about that!  Actually I always have it 
this way so that I can use the temp files!

> And here I have a question/request about rec_imp myself:
>
> It would be nice if rec_imp could be extended to take a filter file
> (say, computed by drc) as optional argument. When given then this filter
> should be applied to the generated sweep before it is played.
> This way it would be very convenient to do some test measurement with
> correction turned on. 
> (I guess that everything which is needed for this is already in the code 
> rec_imp. But the expert could probably implement this much faster than I
> could figure it out.)
>   


I agree (partially).  Actually my use case was to do a short sweep and 
note any large peaks and apply some limiting to the sweep to avoid the 
big bass peaks.  The motivation was that in some rooms you have a 15dB 
peak and some significant troughs.  Given a few dB headroom on the 
recording then this means you loose a lot of dynamic range for the sake 
of not clipping the peak levels

It's not implemented because I wasn't 100% sure that it could be 
implemented properly using only the simple inversion method I was 
using.  Without at least carefully adjusting the amplitude I would 
assume you introduce some spectral leakage which isn't accounted for 
using the simple technique used here...?  I haven't yet tested though.  
It should not be difficult to do a proper deconvolution instead though 
and I believe this is what Uli's sweep utility uses? (Uli?)


However, I am not sure about the complete merits of recording a sweep 
with the full correction in place - you need to have some confidence in 
the maths if you believe these techniques work at all.  I guess it's 
nice to demonstrate this stuff empirically, but you really need to 
analyse it differently as a result (ie using similar smoothing to that 
used by the DRC optimisation process)

Good luck

Ed W