Hello all!
My DSP application is implemented on a FPGA using VHDL. Basically there are four 16-Bit PCM audio signals with 48k sample rate.
After processing each audio signal separately (one multiplication with a factor that depends on a sensor) i add those four audio signals to get a unified signal.
So the question is now, when i add those four audio signals i get a 18 bit result, but i must reduce the bit depth back to 16 bit to hand it to the audio codec chip (DAC).
Should i dither in this case? Or what is the typical approach when adding PCM audio signals and then want to go back to the original bit depth?
All calculation is done in fixed point.
I'm not a DSP expert, but my
intuition says that after summing 4 uncorrelated signals the "16th bit" (bit zero) is already sufficiently randomized, so you don't need dithering.
I assume you can't hear dithering at 16-bits anyway, or you wouldn't be asking... I can't hear anything 80-90dB down...
when i add those four audio signals i get a 18 bit result
Shouldn't that require 20 bits?
Edit - Nevermind.. 18 bits is enough.
Hello all!
My DSP application is implemented on a FPGA using VHDL. Basically there are four 16-Bit PCM audio signals with 48k sample rate.
After processing each audio signal separately (one multiplication with a factor that depends on a sensor) i add those four audio signals to get a unified signal.
So the question is now, when i add those four audio signals i get a 18 bit result, but i must reduce the bit depth back to 16 bit to hand it to the audio codec chip (DAC).
Should i dither in this case? Or what is the typical approach when adding PCM audio signals and then want to go back to the original bit depth?
All calculation is done in fixed point.
The global rule is that whenever you reduce the resolution of a digital signal you will have a new quantization error that needs to be randomized (dithered).
When you process each audio signal separately and reduce its gain, the same rule applies unless you are able to carry forward all of the bits generated by the multiplication.
The other option is that if the DAC permits 24-bit audio input and you're not restricted by something like a serial link's data rate, just send that.
Technically, dither is required as Arnold says, and with certain test tones, lack of dither may become audible. The digital multiplication of one signal may also increase the bit depth beyond 18 bits. It would be best practice always to dither.
With real music at normal volumes, in practice, I'm not aware of any sources demonstrating that lack of dither has been shown to be audible in double-blind tests, but it might show up in deep fade outs turned up way beyond normal listening levels, so there can be practical scope to make engineering compromises if resources are tight.
I'm not that familiar with current FPGAs and programming in VHDL, but you can probably get away with a fairly short sequence pseudorandom number generator to sufficiently decorrelate the truncation error from the signal, thereby not requiring huge numbers of gates to be spent on dither architecture if your resources are limited, though I suspect modern FPGAs have so many gates that it's not an issue for most designs, so why not use the best available.
If resources become tight, the engineering choice depends a lot on what you can know about your signals and their noise content. I guess with audio signals, noise is sometimes going to be at or below the 16th bit level, so dither is preferable.
There can also be potential issues with quantization error if there's not sufficient noise on the analogue side in certain types of ADC (not delta-sigma, but potentially SAR), so that's potentially just as important (or just an unimportant!) as DSP dither, depending on your architecture.
Thanks for the answers. So each time i drop bits e.g rounding after mult or add i have to dither because i will do a new quantization.
If the difference is audible or not is not really important because its a university project
If you are carrying out calculations to a higher precision than the target bit depth then only dither as part of the final stage of bit depth reduction.
If you are carrying out calculations to a higher precision than the target bit depth then only dither as part of the final stage of bit depth reduction.
Yes. This trades register length for less overall processing. If you've got the register length to pull it off, just add the 4 numbers and divide the result by 4 after adding the dither. Depending on how close to the metal you are programming, you can substitute shifting right 2 bits for dividing by 4.
VHDL IS the metal.
He has access to all the individual bit "lines" so he can probably just connect those so the former bit 2 becomes bit 0, bit 3 becomes bit 1 etc. and leave former bit 0 and 1 unconnected.