Archive for January, 2010|Monthly archive page

Can I connect a microphone to line-in?

In Questions on January 23, 2010 at 11:55 AM

These are a few notes from reading articles on the web trying to answer this question.

A simple sound card usually has line-in, line-out, and mic connections. Line (line level) refers to the strength of the signal. Signals from microphones (or pickups from guitars) are typically weaker than line level and have to be amplified.

The mic input on a sound card probably has some amplifier but I was not able find out exactly how this worked. There also seems to be a difference between “computer microphones” and more advanced microphones. If you use a more advanced microphone you probably plug it into a mixer which has a preamp. The output from the mixer can then be connected to the line-in on the sound card.

Or is the only difference between a “computer microphone” and a more advanced microphone the connector? It feels like a more advanced microphone requires a better preamp than the one that (presumably) sits behind the mic input on sound cards.

Furthermore, the difference between a sound card and an audio interface only seems to be that an audio interface is a more advanced sound card: better AD/DA converters, lower sampling latency, and better sampling rates and bit depth. It is also common for audio interfaces to be external. Maybe because they often provide more inputs and outputs.

If you know anything about how the mic input on regular sound cards works I would be happy to read your comments about it.


Unit testing revisited

In Programming, Timeline on January 4, 2010 at 9:57 PM

Every time I make a new release of Timeline I get a little nervous. Nervous that the program will not work or do something unexpected. One obvious activity that helps find bugs in the program is testing. Usually when I work on a new feature I try it out as I go and make sure it works. The problem is that I can’t say with confidence that other features still work: features I haven’t touched for this release or haven’t used in a long time.

One solution is to test all features before every release. That is a tedious job. Especially when you make releases often as we do (once a month). I have experimented a little with unit testing but find it quite difficult. We only use it in a few places to ensure correctness of a few functions. A podcast and an article pushed me intro trying unit testing again and also working in a test driven development fashion.

The podcast

In FLOSS Weekly 87: Extreme Prgramming With Kent Beck topics such as extreme programming (XP), test driven development (TDD), pair programming, and design patterns are discussed. It does a great job of demystifying these buzzwords and makes you understand the core ideas behind them.

In particular I like the fact that they go back and talk about a well designed program as one that has low coupling and high cohesion. Later they talk about how techniques such as TDD help achieve that.

The real eye-opener for me after listening to this show was that the purpose of writing unit tests is not only to test the correctness of a function: it is also designing your code in such a way that it can be tested. And if it can be tested it probably has low coupling and high cohesion which in turn makes it a well designed program. Kent mentions in the show that having the correctness of a function tested is just “a really nice side effect” of writing unit tests.

The article

Now I had a slightly more positive attitude towards unit testing and I wanted to try it out in practice by refactoring some code for Timeline. One thing that is typically difficult to test automatically is GUIs. In Timeline there is at least one GUI component that is quite large and contains much logic. I would be really happy if we can test it automatically somehow.

Browsing the net for answers I came across this excellent article: The Humble Dialog Box by Michael Feathers (found via How can I unit test a GUI?). It describes a totally different approach to designing GUIs that really fascinated me. You remove almost all logic from the GUI and instead put it into another object which can much more easily be tested.

The experiment

I decided to try the idea with a humble dialog box on the category editor in Timeline. It is a very simple dialog which makes it suitable for trying this approach.

For those of you interested, you can read the source code for this dialog before and after (source code for test).


Although the overall length of the code increased I think the separation between the GUI and the controller (the logic that was previously in the GUI) is slightly more readable. Most of the code fore the GUI is now extremely simple. So the increase in code size is not such a big issue I think. It also feels quite nice to be able to test the simple logic of this dialog.

I am still not convinced that unit testing is the answer to all problems regarding ensuring high quality. And maybe that is not the case either. After all it is just one means to get high quality code. I think doing code review is another good means to that same end. I might try this approach again on a more advanced dialog.

A side note

The Flawed Theory Behind Unit Testing (from Michael Feathers’ Blog) expands on the idea that unit testing is just a means to an end where the end is high quality code. From the post:

In the software industry, we’ve been chasing quality for years.  The interesting thing is there are a number of things that work.  Design by Contract works.  Test Driven Development works.  So do Clean Room, code inspections and the use of higher-level languages.

Go read the whole article if you are interested in knowing what it is that makes the above mentioned things work.