Diverting Low Level Audio

Hi Byron,

Once two signals are mixed together, it's extremely difficult to separate them based on level. For example, if you have a recording of a rock band playing, and in the recording there is somebody speaking softly, it's nearly impossible to detect and isolate the quiet speaking voice from the overall signal.

This type of processing is called "Source Separation", and it is a very difficult problem in signal processing. There certainly have been advancements in this area in recent years, but this type of processing is well beyond the capabilities of a SigmaDSP. For more information, you can read this article: http://en.wikipedia.org/wiki/Source_separation

Thanks Brett. In this case, I'm not looking to remove it (initially), simply funnel low level audio onto an alternate path in addition to staying in the original audio path. Maybe this is semantics and we are still talking about the same thing.

My end goal (as you likely already realize) is to still try and do some additional noise reduction by taking this low level audio (if it can be diverted) and invert it, then sum it back to the original audio channel but it's sounding like I'm beating a dead horse .

The things I've tried so far involve binning numerous individual frequencies and then noise gating those independently which works fairly well, however my customer still doesn't like the audible effects that go with that even though it does truly reduce the noise.

HI ByronS:

Are you interested in redirecting the entire signal into a separate path once it goes below a threshold? If so, this should be easy by using an externally controlled switch triggered by a measurement of your signal (RMS or PEAK)

Let me know if this makes sense.

Miguel

Thanks Miguel. Unfortunately no; I need to try and find creative ways of achieving some noise reduction and I thought it might be possible if I could divert only audio below a threshold to an alternate path as detailed above and not the entire audio signal. Was hoping to use the feedback tool to apply an inverted signal to the original as a means of subtracting the un-wanted low level noise from the higher level I want to keep.

Like Miguel mentioned, it's possible to divert the entire signal based on level, but it's not easy to separate a portion of the signal based on level alone. It's quite easy to separate signals based on frequency (using filters) assuming their bandwidths don't overlap, but unfortunately if you have two sources that occupy the same frequency range, and at separate levels, it's not an easy task to separate them.

Try the dynamic processor with the curve as shown.

Play with the (-50,-90) point to set the attenuation of the low level signals.

Play with the (-30,-30) point to set the low level threshold of the input signal.

This will be the signal with the low levels attenuated. Original signal minus this signal will be the low level signals only.

I hope this helps.

Thanks RMD, I appreciate the input, but the problem with this method is that it only provides noise gating. As soon as I have legitimate audio which is higher level coming through, all the low level stuff comes through with it regardless of where you gate it (unless you gate it so high that you get rid of legitimate audio also). I've played with the gating already, and for my application it doesn't solve anything.

Hi Byron,

Perhaps your boss is too critical! (sorry)

The frequency-switching arrangement we devised together at https://ez.analog.com/thread/37954 used a slew volume control to gate each frequency bin on and off:

Problem is, this volume control slews at the same rate up and down, forcing a compromise. You would really prefer a fast attack, slow decay to provide the most natural sound. While experimenting with a similar circuit for music, I've found a more refined method as shown below:

With this version, the Running Average Envelope block provides a rapid turn-on response, but ramps down smoothly. You can tweak the attack and decay independently as needed. Perhaps this will meet your requirements.

Best regards,

Bob

Thanks Bob. So far the binning solution you provided in the post you just mentioned satisfies the boss just fine, just not the customer........who I guess is the ultimate boss anyway.

Would it be safe to say your alternate method just detailed would be even more resource intensive then the original solution? As you recall, the original method used a lot of instructions, which means I'm right up to the limit already.

I've been playing around with the slew rate of the volume controls on the original binning method and that seems to remove most of the audible effects from the gating when I slow them down. I'm hopeful this will resolve the issue sufficiently since the primary complaint is the audible switching of the gates.

Hi Byron,

I have a cat, so I know all about fussy customers! I'm not sure how much the instruction count would increase. The new arrangement adds another dynamics processor, but replaces a slew volume with a much simpler multiply. If you compile your present design, save-as and change one bin to the new way, you could compare instruction usage.

Bob

Hi all:

Since resources is a concern in this thread, I thought it might be a good idea to streamline and optimize this code that Bob suggests and add it to SigmaStudio as a generally available library. Bob, can we do this, knowing many of these concepts are yours? Byron, please comment on the quality of this solution to validate the effort in optimizing the code and making it a generally available library.

Miguel

PS. The real boss is my wife

Hello Miguel,

That's certainly fine with me. My efforts to perfect binning noise reduction have run into MIPS limitations, so the ability to optimize at the block level might be just what it needs.

Best regards,

Bob

That's fine with me also. I'd love to see what kind of resource reduction could be achieved by doing this. As long as there is still the ability to externally control the gate thresholds (I'm currently using an external pot), as well as being able to input a number into the control for setting the slew rate of the gates.

Just a follow-up to Bob's suggestion above for using a running average envelope detector instead of a slewing volume control. For my specific application with the # of bins currently being used, it requires an additional 252 instructions which puts me well above the 1024 limit (reports 1213 in the compiler error). As a result, I can't comment on what level of improvement in audible performance this may provide.

If I get time, I may strip down the # of bins being used to get under the limit, and then run a comparison at that level.

Hi Byron.

A bin logic scheme that fits into a -1701 is shown below. It uses about 20% fewer instructions than what I've previously been using, while maintaining separate control over attack and decay times. Depending on what else is included in your overall project, this may allow you to keep the full 16 bins, or at least reduce the number you need to take out.

Though it appears rather intricate, it uses only simple blocks. It saves on instructions by getting more mileage out of the ABCD Comparator, which now performs the whole fast-attack, slow decay function with the help of the feedback block and a little math. Here's how it works: With the sound level above threshold, the ABCD Comparator selects its C input. This is its own output plus a small number labeled Attack above. Each sample interval adds the Attack amount as long as the sound is above threshold. When the output reaches 1.0, the AB Comparator in the loop freezes it there (A Clipper block would have worked as well, but the AB Comparator is more economical). The 10-90% rise time Trise = 0.8 / ((Attack) x fs). With below-threshold sound, the active D input is the loop output times the number labeled Decay -- which is set just below 1.0. Each sample interval multiplies by Decay again, setting up the first-order differential equation dy/dt = y x (G-1) / (1/fs) = y x fs x (G-1). The result is the exponential decay, y = e^(fs x (G-1) x t). The resulting fall time is Tf = 2.2 / (fs x (1-G)). Adjusting these numbers sets the bins' rise and fall times. All this shows the power of feedback and math to accomplish needed functions in a uniquely economical way.

The attached project implements the above bin logic with all 16 filters. At first I heard stuttering in the podcast I was listening to, only to find the same when plugging my headphone directly into my laptop. Turns out it can't handle the mp3 and SigmaStudio's live USBi connection together. Threshold adjustment works similarly to the original design. I've also experimented with having the threshold adapt by summing in a slow envelope of the overall input, which you can add in if it fits and you're so inclined.

If you need to change the number of bins, space them by a constant multiple. When spaced this way the Q of all filters is identical. I'm sure there's a formula to figure the best Q for a given bin spacing, but I experiment by plotting (with the Stimulus and Probe blocks) several filters summed directly. Have fun with your project!

Best regards,

Bob

Presently, the Hold boxes in all the PeakEnv blocks are set to zero. One reason for a Hold setting (which keeps the envelope output at its peak before decaying) is to cover over the valleys between the cyclic peaks in the input waveform. This suggests setting the Hold settings in lower-frequency bands to a few milliseconds. The time between peaks at a given frequency is Thold = 1/2f. Without this, gating in the lower-frequency bands might waver between on and off, should the level there be near threshold. Presently I can't hear any artifacts from this possibility, but maybe your customer can!

Bob

Many thanks Bob! I'll try to get some time testing it out this week and reporting back on my findings. If this proves effective, and ADI can roll this into a generally available library function (as per Miguel's comment), is it safe to assume there could be additional efficiencies achieved in terms of instruction count?

Yes, we would likely be able to make some optimizations if this was created as a single cell in the library. However, Miguel and the software team will have to decide what level of priority they could assign to that project.

I`ve had some time to try and use the optimized method in my project. Purely comparing instruction used, I`m finding my original project used 929 instructions, and the new one takes 1127 (over the 1024 boundary) even after removing the 3800 Hz and 4800 Hz bins like my original project did. I`ve re-checked my project to make sure I`ve removed only the original bin method, and replaced it specifically with the new method and I`m still coming up to the 1127 instruction number. Based on this I`m not realizing a 20% reduction in instructions like your mentioning Bob, but I`ll keep looking to see if I missed something. Haven`t had a chance to evaluate audio quality yet.

Hi Byron,

I'm sorry, when I said "original" I was referring not to the first project with the slew volume controls, but the 2nd one that used the extra dynamics processor and which blew away the MIPS. The latest project uses about 20% fewer instructions than that one, but it does use more instructions than the first one. Sorry for the confusion I caused. I'll have another look and see if anything else could be done. In the meantime, likely you could try about 11 bins, spaced a half octave (square root of 2 multiples) apart, which would cover the five-octave voice range between 150Hz and 4800 Hz. Make a direct comparison between this and the 'real' original design (16 bins with the slew volumes). BTW -- you may want to try tweaking the slew numbers on that first design, to see if you could satisfy the customer better as-is. You didn't mention exactly what they didn't like; I assumed it was perceived choppiness in the voice quality.

Best regards,

Bob

No worries Bob. The latest one I provided to the customer and am awaiting feedback on uses the peak envelope detectors and the slew volume controls (as they originally didn`t like) with the slew rate on the volume controls slowed down so the switching isn`t as audibly noticable (which is what you just mentioned). The problem I had with the Running Average Envelope method was instruction count, so I couldn`t really use it given the other items required in the project. In the short term, when I spun the PCB design, I had little choice but to add 2 EEPROM`s so that I could offer the noise reduction stuff in one (with the high instruction count) and all my other features in the other. I`m hoping if this ever gets to the point of being a standard library function, that all of this could eventually fit below the 1024 instruction count and I could fall back to a single EEPROM.

To answer your other question, the customer characterized the listen audio as though they where `listening to someone in a tunnel.` They also didn`t like the sound of the gates switching in and out. Slowing down the slew rate on the volume controls addressed the later, but I haven`t done anything to address the former. If I can get more bins added back in, I`m hopeful that will start to address it.

Bob, just to give a bit of feedback.........customer is now happy with the latest version I put in their hands. Slowing down the slew rate of the volume control seemed to do the trick along with giving the user control of the noise gate threshold through an external POT.

Miguel: Not that I'll hold you to it, but what rough time frame are we looking at to get this method put into a library part, assuming this is still something you would consider doing?

Hello Byron,

I'm glad you were able to tweak your design to satisfy the end customer. They are always happy to have accessible adjustments, even if in practice they never use them.

Best regards,

Bob

Hi Bob and Byron:

Please find attached the library that works with the latest version of SigmaStudio. The savings are not as much as I thought they would be, but I'm sure, some of you will welcome the additional MIPS. The library is probably at a state not ready for SigmaStudio, I have heard that support for higher frequencies might be a need so perhaps it should be more flexible. I would like to here your comments to see how we can improve it further and make it more flexible.

PS. the initial HPF filter is not included.

Thank you and happy holidays.

Regards

Miguel

It appears that the add-in block itself disappeared in the Jive Software to Telligent transition. I found it in my archived stuff and attached it below.

Bob

FullFSNR.zip

Miguel,

Wow, that's wonderful! I'll try it soon and let you know how it works.

Byron -- in case you don't know, you can add this library to the toolbox this way:

Unzip the FullFSNR.dll file

Copy it to SigmaStudio's program directory (where you'll see similar files)

Start SigmaStudio

You should see it under ADI Algorithms / Noise Reduction

If not, open the Add-Ins Browser in the Tool menu, and make sure the library is checked.

Bob

Thanks guys. I really appreciate how fast a prototype has been made available for the library. I also appreciate the instructions Bob as this is not something I've done before. Between other issues to deal with in the short term and the holidays, I thinks it's going to be into the new year before I can have a decent look. I also have to get the newer version of SigmaStudio loaded by the sounds of it, since I'm still running V3.8. As soon as I can I'll report back.

Hello Byron & Miguel,

I've run some tests on the new algorithm -- it compares favorably to the discrete implementation first described at:

https://ez.analog.com/message/122872#122872

I'll publish my test results in a new thread when time is available.

Best regards,

Bob

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin