freeverb noise ?

Status
Not open for further replies.

emmanuel63

Well-known member
Hello,

I am testing the freeverb object. I use exemples/audio/effects/freeverb. I use short audio samples to see how the reverb tail fades. I have noticed that there is quite a lot of noise in that tail. There are threads about this issue but I couldn't find solutions. Where does the noise coming from and is it possible to avoid it ?

The noise comes from the freeverb object. When I bypass it, my audio output is clean. It is not a ground problem.

Emmanuel
 
I have had this problem also. Here are some things that helped for me.
-Have a wet/dry control, If all the sound goes through the reverb you will get more noise, so have some of the dry sound mixed in.
-Low pass filter on output of reverb. I used a state variable filter to lowpass filter the reverb - this really helped remove much of the noise.
-Lower input gain. I found that reducing the amplitude of the input signal and then amplifying it afterwards helped reduce noise (though i'm not sure why)
 
I discarded that reverb because of that noise, haven't try to filter the output btw (got a filter in the input because low frequencies overload the reverb input pretty easy).
A better quality reverb object with more parameters would be awesome btw.
 
Is this simply a consequence of 16 bit intermediate results in the freeverb object? 16 bits is enough for a signal, but not usually
sufficient for complex processing of signals as quantization/rounding errors accumulate.
 
Is this simply a consequence of 16 bit intermediate results in the freeverb object? 16 bits is enough for a signal, but not usually
sufficient for complex processing of signals as quantization/rounding errors accumulate.

/\ This. I'm a big supporter of anyone who wants to help build out the F32 library or at least a 24 bit one.

Filtering really helps.

I need to work on my filtering. My project is close, but still too much noise. Using the Float 32 library helped fix a ton of noise and headroom issues. I'm currently using TDM inputs -> Int2float -> mixer and processing -> float2int -> TDM and I was able to reduce the noise quite a bit. But I pulled the signal back out of F32 (float2int) and then processed with reverb, and sent it back into the mix (int2float) and the Freeverb process was too noisy. Luckily latency was still ok! A F32 TDM input library would probably reduce noise. Also a FreeVerb_F32 would also help... For now I'm going to be working on my filters.
 
I have been working on a new reverb implementation on the Teensy4.0 recently. The algorithm is inspired by the Alesis allpass based reverbs, a fully stereo in-stereo out, using internal lfos to modulate the delay lines and create a lush long and nicely spread reverb tail. The sound sample is here:

https://soundcloud.com/hexeguitar/t40gfx-plate-reverb

It has most of the useful sound shaping tools:
- reverb time
- diffusion - how much "echoey" the reverb is
- high band loss
- low band loss
- master lowpass filter
I have experimented with adding pre-delay, too, but after tests the impact of the sounds was too tiny for the the price in increased RAM usage.
Data is converted into float32 and all operations are run as floats to be converted back to int16 at the end, so it's compatible with the standard audio lib and it's i/o operations. The tail fades out very smoothly without that metallic ringing present in the freeverb code.
It's written for Tennsy4 only and is a part of larger guitar FX project including IR convolver for speaker simulations and, currently in the works - a stereo doubler effect to mimic multiple rerecorded guitar tracks.
I hope to post it soon, the code needs more cleanup, also i'd like to create an example project with i2s input and wave player for testing. I'm not using the arduino ide, but platformio, though.
 
I was going to add CPU load measurements but managed to fry the codec chip. Center negative 9V barrel jacks are dangerous with their exposed +9V ring. Must have touched something that instantly fried the chip. Luckily the T40 survived, had a polyfuse in the power input. Will replace the chip and repeat the test.
The processorUsageMax for the reverb component was reporting about 5%. Also, i moved all the reverb allpass/loop buffers to DMAMEM, so it leaves plenty RAM for other uses.
With a stereo convolver running an over 6000 samples long IR (speaker simulation) + the stereo plate reverb i was getting about 25-30% load.
This is the base board i designed for the T40, it has the SGTL codec, midi i/o, 4 Pots, footswitch input, two leds and a few pin expansion pin header, like SPI for a small display. Oh, and analog bypass using CD4053.
ktQPV7Al.jpg


s9CMGkol.png


It's a hobby project, which i'd like to open source. I'm building it mainly for my home studio/live looping rig. Something i'll put at the end of the chain, providing speaker simulation, reverb, track doubling and whatever else i'll come up with (wav player for drum loops maybe).
I'll create a new thread about it once i gather more project details.
Not sure if tweeter links will work here, but i posted an interesting reverb comparison when i was working on another project:

https://twitter.com/hexe_fx/status/1327263279455068165

At first i was trying to improve the freeverb by adding a slow modulation to the delay lines. This is a common technique to sort of "smear" the reverb tail, make it less echoey. It did improve the sound a little bit, but the noise/metallic ringing was still audible, only now modulated ;) So, in the end i started from scratch using a different reverb topology, which i often used with the SpinSemi FV-1 dsp. T40 opens up so much new possibilities. This won't be my last reverb for sure! Already thinking about a nice spring reverb simulation.

It sounds like it would port fairly easily to the OpenAudio_ArduinoLibrary (Floating Point Teensy Audio Library).
Yes, fairly easy. I plan to switch to OpenAudioLib anyway.
 
It sounds like it would port fairly easily to the OpenAudio_ArduinoLibrary (Floating Point Teensy Audio Library).
Yes, fairly easy. I plan to switch to OpenAudioLib anyway.

Any chance I can have the code? I'm interested in giving this a spin on my project.
 
Hey Pio, for what it's worth, I think your existing approach to floats is the best compromised approach. Using floating point from end to end is wasteful of a lot of computation. 16-bit transport between effects if fine. Inside an AudioProcessor effect, use the correct precision for the job. if 16-bit ints are fine (e.g. simple delay) use it. If more precision is required (e.g. IIR/FIR Filters) use the 64-bit ints. If precision and big dynamic range is required use float. In audio processing, we do so much filtering that is best handled on the ARM using high precision integer biquads that still run much faster than float. On the other hand, when tube or other non-linear processes are being modelled, you really need float.

If you are running a LOT of separate AudioProcessor effect stages, then I can start to see some value in 24-bit integer transport as you could get enough 16-bit rounding accumulated into something audible. If Paul was going to invest time in revamping the AudioStream, I think 24-bit would be better than float given the approach above can still be used for 64-bit ints and float when necessary.
 
Status
Not open for further replies.
Back
Top