KVR Audio

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 10:41 am

I'm working on a non-audio-related signal processing project at the moment, and just wondered if anyone could help me get my head straight on a point of DSP theory...

To put it simply, in my algorithm I am multiplying an input signal with the output of an envelope follower tracking the same (normalised) signal. So I'm multiplying a signal with its own envelope and this is acting as a low-pass filter who's characteristics are desireable in this application.

So now to the DSP question - we know that time-domain multiplication is the same as frequency-domain convolution, and vice versa. I'm thinking therefore that the frequency response of my (admittedly strange) low pass filter is going to be identical to the frequency response of the envelope follower. It certainly looks that way to me, anyone care to chip in?

Kind regards
Dave

duncanparsons · Post by **duncanparsons** » Mon Jan 17, 2011 11:45 am

so.. it's essentially a self-quietening volume control that keeps the loud bit's loud & the quiet bits quieter - almost a gate with no defined opening & closing..

First thoughts:
Do you really find that acting like a low pass? It doesn't sound like it should to me, other than perhaps the lower frequency content may well have greater energy & thus be driving the envelope follower more than the HF content, but it depends on the spectral spread of the incoming signal.

Depends somewhat on the coeffs of the envelope follower, if it's too responsive you could end up with some odd sidebands from AM artefacts.

Thinking further:
given that you're essentially working with
y = x * env
&
env = y[i-1] + α * (x - y[i-1])

then yes, I do see that it could be seen that you're applying an instantaneous discrete change to a lowpassed signal (rather than how I had first seen it as being the other way around).
I'm not totally convinced that the freq response of the overall system will match that of the single envelope follower component, since I think the AM interaction will disrupt that - however given the low period of most envelope followers, the sidebands might be sufficiently close to each of the carrier's frequencies, and at sufficiently low amplitude, to be discounted.

Anyway, I'm happy to be wrong, if that's the case, since it would present a new learning opportunity!

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 11:54 am

so.. it's essentially a self-quietening volume control that keeps the loud bit's loud & the quiet bits quieter - almost a gate with no defined opening & closing..

That's absolutely spot-on, exactly how I'm visualising it. What I have is six channels of data sampled from a sensor at 20hz. The sensor isn't brilliant, so there is some jitter in the signal which is essentially random. For our application, we want to remove small, high-frequency variations from the signal and leave big, low-frequency variations (though the signals are not really periodic due to their nature).

I'm of the opinion that the envelope follower is slow enough not to make much of a difference. What I'm looking for is a way of comparing how various algorithms I've got in my toolbag perform, and I need some objective basis for that such as a frequency response. Hence the question should perhaps be "how do I derive the frequency response of the overall system"

Perhaps best just to bung a dirac impulse in and FFT the results and not worry about the theoretical side of it...

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 12:52 pm

Deriving the frequency response with a dirac impulse answered my question. The frequency response of the overall system is not the same as the frequency response of the envelope follower because when there is no input, there can be no output. So yes, the amplitude modulation affects the frequency response alot.

Sometimes you just need to bounce these things around!

Kind regards
Dave

hugoderwolf · Post by **hugoderwolf** » Mon Jan 17, 2011 12:54 pm

Muon Software Ltd wrote:Hence the question should perhaps be "how do I derive the frequency response of the overall system"

I think you don't at all, because the system is not LTI. There is no way to describe it in terms of a frequency response.

What you could do is derive the output spectrum from a specific input spectrum. As a first guess, I'd say it is the input spectrum, convolved in frequency domain with some kind of a lowpass version of itself.

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 1:05 pm

the system is not LTI

In that the frequency response of the system is dependent upon its input, yes I think you are right. So the dirac impulse is not telling me what I thought it was, its only telling me the frequency response for that particular input signal.

What you could do is derive the output spectrum from a specific input spectrum. As a first guess, I'd say it is the input spectrum, convolved in frequency domain with some kind of a lowpass version of itself.

That's a very good explanation, thank you.

I wonder then on what basis I can evaluate the noise-removing performance of various different algorithms, some of which are LTI and some of which are not...

antto · Post by **antto** » Mon Jan 17, 2011 1:15 pm

so, input is a sensor sampled at 20Hz..
this means you got stuff from 0 to 10Hz
what is the useful range of the actual content?

if you multiply the signal with peak follower of itself - you are waveshaping with frequency dependance, this is cool for a distortion effect, but i guess it's not good for removing high-freq content

why not use a steep IIR lowpass on the input instead?

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 1:26 pm

so, input is a sensor sampled at 20Hz..
this means you got stuff from 0 to 10Hz
what is the useful range of the actual content?

Unfortunately the signals are not particularly periodic in nature.

why not use a steep IIR lowpass on the input instead?

I'm looking into it, but its very difficult to define exactly what the frequency response of the filter should be. So I'm looking at algorithms that "work" and trying to ascertain what their useful characteristics might be.

The advantage, by the way, of the envelope detector is that I need store only one previous sample of my output and do a couple of adds and a multiply each sample. Unfortunately it needs a branch, but so far the performance is pretty good. Performance unfortunately is where its at with this app - the sensor is actually a webcam, and some heavy-duty image processing is being done on the image. The bit that gathers the sensor data and cleans it up needs to be as fast as possible because we're then pushing that data into a big 3D simulation which consumes CPU like there's no tomorrow.

jupiter8 · Post by **jupiter8** » Mon Jan 17, 2011 1:27 pm

Muon Software Ltd wrote:For our application, we want to remove small, high-frequency variations from the signal and leave big, low-frequency variations (though the signals are not really periodic due to their nature).

Isn't this a job for a moving average filter ?

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 1:32 pm

Isn't this a job for a moving average filter ?

We've tried an EWMA (exponentially weighted moving average) filter, but it didn't seem to work very well. The guy that worked on it thinks there might have been an implementation bug and I'm looking into that.

The thing with filters like this is you need to store a lot of previous values, so more memory and more CPU. If you consider that a moving average is basically a low pass filter then there are lots of alternatives

jupiter8 · Post by **jupiter8** » Mon Jan 17, 2011 1:40 pm

Muon Software Ltd wrote:The thing with filters like this is you need to store a lot of previous values, so more memory and more CPU. If you consider that a moving average is basically a low pass filter then there are lots of alternatives

They're pretty useless in the frequency domain to filter out certain frequencies but they're great in the time domain to smooth out waveforms.

CPU wise it's one addition and one subtraction per sample,can't get much cheaper than that. Memorywise would obviously depend on the length of the filter.

antto · Post by **antto** » Mon Jan 17, 2011 3:55 pm

Muon Software Ltd wrote:The advantage, by the way, of the envelope detector is that I need store only one previous sample of my output and do a couple of adds and a multiply each sample. Unfortunately it needs a branch, but so far the performance is pretty good. Performance unfortunately is where its at with this app - the sensor is actually a webcam, and some heavy-duty image processing is being done on the image.

oh, performance is important.. okay
well, if the cutoff frequency of the filter doesn't need to be changed - you can try a 4th or 6/8th order Besself filter, it's only a few multiplications and additions.. tho, IIR filters and image processing, i think you need to filter bidirectionally and combine the results..

The bit that gathers the sensor data and cleans it up needs to be as fast as possible because we're then pushing that data into a big 3D simulation which consumes CPU like there's no tomorrow.

this smells like this "kinect" sensor thing, isn't it?

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 4:29 pm

CPU wise it's one addition and one subtraction per sample,can't get much cheaper than that. Memorywise would obviously depend on the length of the filter.

I found an IIR implementation of the EWMA which works out to be just three arithmetical operations and needs one previous sample of output in memory. It works very well in terms of performance.

The envelope detector does have the advantage however that I can configure a seperate "smoothing" value for both attack and release, which is very nice in this application.

this smells like this "kinect" sensor thing, isn't it?

Nope, just a regular webcam. Kinect would rock though in this application, no doubt we'd get much better input data. No doubt someone out there is already working on it

duncanparsons · Post by **duncanparsons** » Mon Jan 17, 2011 4:59 pm

Muon Software Ltd wrote:Nope, just a regular webcam. Kinect would rock though in this application, no doubt we'd get much better input data. No doubt someone out there is already working on it

What, like this. A friend of mine is doing a PhD in interactive dance, and I've suggested she have a close look at that article with her CS assistant.

Muon Software Ltd · Post by **Muon Software Ltd** » Mon Jan 17, 2011 5:14 pm

The application in question is a head tracker. We use FaceAPI and get an estimate of the position of the user's head. That is mapped into a camera position in the 3D world, which in this case is a flight simulator. There are lots of apps that do this with infrared cameras but they all require the user to wear a special infrared reflector or emitter on a hat (Freetrack, TrackIR). There is a non-infrared tracker (Cachya) that requires a special logo on the hat also.

Personally, I don't like wearing hats or having infrared LEDs hanging off my face so for me this what this new software does is something new and very cool.

As you can imagine though, FaceAPI has difficulty in estimate the position of the head just using 2D data, hence the need for filtering. I would have thought a 3D sensor would make things much easier, and no doubt someone out there will do it - when they do, our app could easily be adapted

Multiplying a signal with its own envelope