[sdiy] 12 bit quantization noise, dithering, synths

[brianw]

The first time I moved from "audiophile" digital audio to video game audio - writing a digital mixer to combine multiple sounds effects in a game - I quickly ran into challenges with the signal-to-noise ratio. Strictly done, an 8-channel digital mixer would only allow 5 bits per input channel to avoid clipping. Not only that, but you can barely hear the game audio when a single channel is present. So, I walked to the office of one of the video game experts, and asked how they managed to get decent quality out of a mere 8-bit DAC. The answer? Don't allow any headroom! Run all samples at full volume! They'll rarely correlate enough to clip, and even if they do clip, that will be better than not being able to hear the samples, not to mention losing the input sample details to further quantization.

In the DX-7, and all the Yamaha FM synths, you'll note that the number of carrier operators on the bottom row of the algorithm determines the amplitude of each carrier. With a single operator on the bottom row, the carrier is at full volume. With two operators on the bottom row, each is -6 dBFS, because Yamaha doesn't allow clipping on output. Four operators: -12 dBFS each carrier. Six operators - useful only for pipe organ sounds - and each is -15.6 dBFS. They get decent performance by using a 16-bit DAC (on all but the first revisions).

I don't know if it could work, or if it would sound okay, but you might try running all carriers at full amplitude. Then again, that might be a short-lived experiment. FM synthesis isn't like sampled sound effects. You'd have better S/N, but potentially horrible THD!


A hardware solution that I never implemented is to use an MDAC - or Multiplying DAC. This allows the samples to be converted at full amplitude resolution, while another input (EG) scales the analog voltage. I couldn't find any MDAC chips at the time (three decades ago), and the problem is that you can't always feed audio into the analog reference input of a DAC because those inputs are often filtered, with the assumption that the voltage will not change at all.

Theoretically, though, you could use one 8-bit DAC for the audio waveform running at full amplitude all the time, feeding the analog output to an MDAC where a digital EG value would control the attenuation of the waveform without any re-quantization of the waveform itself. In your case, with a 12-bit DAC internal to the CPU, you might be able to use an external MDAC to apply the envelopes. The down side is that you'll need a DAC channel for each individual carrier.


The point is that there are clever analog and digital techniques for cutting corners that aren't strictly by-the-rules, but will work.

Brian


On Feb 10, 2023, at 1:58 PM, Tom Wiltshire wrote:
> To answer the other part of your question, plenty of the "historical" 8 and 12-bit audio systems used non-linear DACs or companding to extended the dynamic range. So what you were listening to *wasn't* a simple 8-bit output.
> 
> As you've noticed, the problems are far worse at low amplitude levels where the quantisation noise becomes a significant portion of the signal level. So if you can keep the signal louder, you can reduce the problem. Some systems (Synclavier, for example) did this by using multiplying DACs, and generating the audio at full volume, and then applying the envelope to the DAC's reference voltage. This maintains the full 8-bit (or 12, whatever) resolution all the way to the very quietest output.
> Using an expander to "squash" the output volume rather than trying to create it digitally is another way, and non-linear DACs like the AM6070 are another way. They use what is roughly a very basic floating-point format with some bits of data and some bits representing how many shifts the data should get, or equivalently, what voltage range it should get scaled into. The Casio CZ series did something similar to avoid the need for a more expensive DAC - it used a cheaper DAC with less resolution, but then scaled the output according to the MSBs.
> 
> Tom