The best kittens, technology, and video games blog in the world.

Friday, January 05, 2007

Blinkenlights, part 2 - sound cards

~Little Ginger Tabby~ by *Sage* from flickr (CC-NC-ND) Parallel port seems to be the right way to go, but it wasn't my only idea. As a short detour of the real story, here's a bit about another way of communicating with a computer - a sound card. Sound is a pulsation of air. Sound cards have absolutely nothing to do with sounds. What they actually do it converting digital signals from computer to analog voltages on the line (to speakers), and analog voltages on the line (mic) to digital signals for the computer. Conversion between the analog voltage and the "sound" is actually performed by the speakers, headphones, mic, and so on. Of course there's absolutely no reason for plugging only sound devices into sound card ports. Long time ago I tried to make computers talk with each other, by plugging one's speaker port to other's mic port, and creatively perlscripting (they did have ethernet cards, it was just for fun). I actually expected the numbers send to the sound card and received from the other sound card to be identical, except for some noise and linear scaling factor. It turned out not to be the case. When I sent the sound and played what was received, it was pretty similar, but when I tried to pass arbitrary data, there was hardly any similarity between data sent and data received. I guess there are some low/high-pass filters, and other stuff on the way, good enough for sound, but making it really difficult to use it for anything else. Fast forward to a few years. When I was trying to build some blinkenlights display, before I even thought about the parallel port, my thoughts went to the sound card. The first thing when dealing with any electric device is grabbing a multimeter and verifying what really happens inside. Sound cable has one pin divided into three parts. One is ground, the other two are left and right signal. Using a meter on that is trivial. So I flooded /dev/dsp with various kinds of data, and observed on the multimeter what was happening. First I tried constant data, and DC (direct current) voltage meter. It was almost hopeless, something did happen, and I was able to affect the results, but the relation was very weak and unstable. Then I thought - sound cards are not really for DC, sound is an AC phenomenon, so how about trying some constant-frequency sounds and using AC (alternating current) voltage meter ? In retrospect it seems obvious - but DC is so pervasive in computers, that my mental processes associated AC with "this weird high useless voltage thing that enters the power supply unit, and gets converted to some useful (that is - low voltage DC) kind of power". And it worked - I could reliably control ACV reading using the following snippet of Octave (Octave has nothing to do with sound, it's a numerical computations programme) code:

len=10; freq=50; cycle_per_sec=8000; mV=50
X=[mV*0.55*sin((1:(len*cycle_per_sec))*2*pi*freq/cycle_per_sec)];
playaudio(X)
mV was number of milivolts I was getting on the multimeter, plus minus a couple percent. The most I could reliably get was about 350mV. What does it all mean ? Well, nothing really. It's just distorted low-bandwidth signal in highly inconvenient form (350mV ACV). Sure, if I really felt bored, I could convert ACV to DCV by a simple diode, and increase the voltage to some decent level (5V DCV or 3.3V DCV, depending on family, I need 5V DCV for 74LS), but other interfaces like parallel port seem far more promissing. And that's what I'm going to explore in the next part. See also: Blinkenlights, part 1.

No comments: