## The 1 bit = 6 dB Rule of Thumb, Revisited.

March 28, 2017

Almost ten years ago I wrote an entry about the “1 bit = 6 dB” rule of thumb. This rule states that for each bit you add to a signal, you add 6 dB of signal to noise ratio.

The first derivation I gave then was focused on the noise, where the noise maximal amplitude was proportional to the amplitude represented by the last bit of the (encoded) signal. Let’s now derive it from the most significant bit of the signal to its least significant.

## 8-bit Audio Companding

February 7, 2017

Computationally inexpensive sound compression is always difficult, at least if you want some quality. One could think, for example, that taking the 8 most significant bits of 16 bits will give us 2:1 (lossy) compression but without too much loss. However, cutting the 8 least significant bits leads to noticeable hissing. However, we do not have to compress linearly, we can apply some transformation, say, vaguely exponential to reconstruct the sound.

That’s the idea behind μ-law encoding, or “logarithmic companding”. Instead of quantizing uniformly, we have large (original) values widely spaced but small (original) value, the assumption being that the signal variation is small when the amplitude is small and large when the amplitude is great. ITU standard G.711 proposes the following table:

## Coding by ear

September 22, 2015

I just got one of my computer’s fans repaired. It was still working, but noisy like a diesel engine. While I started savoring the relative quietness of my study again, I noticed that I lost something with that repair. I lost a source of information about what my computer is doing.

The fan speed—and noise—varied with the CPU temperature, which in turn varies with its clock speed and workload. The harder the machine works, the noisier it got. At first, you night think (correctly, for that matter) that having a noisy computer is annoying, but I think you can turn that to your advantage while coding.

Having an actual, noisy, grinding fan is an annoyance. But what if we paid attention to the noise our computer makes, use it as a development tool?

It’s easy to forget that a computer is just a machine like any other, and that an intensive computation, in addition of taking time, also consumes power, dissipates heat, and cause wear—especially when disk IO is used intensively. Therefore being aware of what our code does to our computer may make us better coders.

If you don’t benefit from a noisy fan, you can still use the machine’s sensors to keep you informed on what goes on in your box.

• Sensors. You can use Linux’s sensors command to get a snapshot of your box’s health. The package you need to install varies from a distribution to another, on Debian-like it’s the package lm-sensors. Invoking sensors, maybe within a pretty-printing script, combined with watch (say, watch -n 1 sensors) will let you see what happens.
• htop, iotop, and nethogs. htop is a prettier, configurable, version of top. It does the essential: processes, process trees, threads, etc. The iotop command needs to be run as root, but will show you what happens with disk IO. nethogs does the same thing for network bandwidth.
• Conky and other system monitors. A good while ago, I wrote a piece on conky, a simple but highly configurable system monitor. It’s kind of old school (no rounding plasma 3D widgets) but gets the job done. I’ve integrated sensors to it so it also displays the CPU temperature and fan speeds.

*
* *

Listening to your computer doesn’t replace good software practices (good algorithms, profiling and hunting for hot spots) but complements them. If you hear your HD scratching a whole lot more that it should, you have gained a few bits of information—something unexpected is happening.

*
* *

In a way, that noisy fan helped me refine my code in more than one occasion. It reminded me that I should be coding for a Pentium III (something I think I advocated before), and that if my program was making my computer noisier, then it probably consumed more resources—CPU, IO, power—than it should have. Keeping my computer quiet forced me to write better, faster, more frugal code.

Keeping an eye on the machine exertion symptoms may help you write better code, especially when scaling is considered. If your program adds 20 degrees to your computer’s internal temperature, how will it scale to service a hundred time more requests?

## Filtering Noise (Part I)

August 25, 2009

If you own a car, you probably noticed that the speedometer needle’s position varies but relatively slowly, regardless of how the car actually accelerates or decelerates. Unless your speedometer is some variation on the eddy current meter, maybe the noise from the speed sensor isn’t filtered analogically but numerically by the dashboard’s computer.

Let us have a look at how this filtering could be done.