If you had any remaining doubt that it was time to get off the Microsoft boat, see what they're planning for the Win 7 launch. Make sure you watch until the very end... the guy on the left does a hang 10 sign.

As my friends and family will confirm, I've become a pretty obnoxious Apple fanboy since my switch to Mac. My answer to many general computing problems these days is "get a Mac" a little too often, and a little too pompous. Nevertheless, the attitude comes from a genuine belief that Apple has it right, Windows is doomed, get off the boat while you're still breathing air.

I found an exception. Maybe one that proves the rule, maybe not, but a pretty big exception.

Do not attempt to build a media center on the OS X platform. Don't do it. Apple doesn't want you to succeed.

The core issue is this: the Mac does not play back H.264 video using hardware acceleration, except in some very specific instances. Namely:

• You must be using a Mac with, specifically, an nVidia GeForce 9400M graphics adapter. Mac Pros need not apply.
• You must be using the native Apple H.264 decoder. If you use an alternate player (like VLC, for example), no dice.
• The H.264 video must be encoded using the "main" or "baseline" profile. This means that some H.264 videos (the ones that use features from the "advanced" profile) will "gracefully" degrade to software decoding.

So what's wrong with decoding H.264 video in software? Nothing, if you're willing to dedicate 1.5 cores to the process and settle for occasional jerkiness and sync issues. Seems kind of silly to not be able to play back 1080P video smoothly on a $4,000 Mac Pro with multiple high-end video cards, doesn't it?

I'm not going to go into why this is the way it is, but believe me when I say I've looked for workarounds. The 9400M is one of the very few nVidia parts that uses the G98 chipset, which incorporates version 3 of their PureVideo HD technology (most other, current nVidia parts only include version 2, because nVidia discovered that the additional capabilities offered in version 3 could just as effectively be dealt with in drivers). Anyway, I actually found a nVidia card that uses a G98 (the ASUS EN8400GS Silent) but was still unable to get hardware accelerated H.264 playback.

I hemmed and hawed on this for a while. Even with hardware acceleration on a 9400M, 1080P playback still sucked 20% CPU. Plus getting AC3 and DTS passthrough is a bitch with QuickTime (just ask the poor Perian team, who has been bending over backwards trying to work around the QuickTime architecture to make this happen). In the end, I decided that this was just too much pain for something that's so easy in XP.

Long story short, I've re-re-built my media center machine using XP SP3. Same hardware, same 1080P H.264 content, less than 2% CPU utilization. And no stuttering.

Now don't get me wrong, both my laptop and my production machine are both Mac and are going to stay that way for a long time. Apple has nailed the desktop computing experience, and my fanboyism is only slightly dampened. But it seems clear that Apple's desire to keep a stranglehold on the media consumption experience has left a big gaping whole where my happiness should be.

It is deceptive to believe that something that works 99.8% of the time is "good enough." As a software developer, I often find myself stopping at 99.8% (or 95% or 90% or whatever) because of the perceived diminishing returns in polishing something to 100%. And most of the time that's the right call. Perfection is not only impossible, it's also prohibitively expensive, time consuming, and ultimately uncompetitive.

There are many things, however, that are 99.8% effective and still effectively useless.

Modern speech recognition is often touted as being 95-99% effective. If you've ever tried to dictate an e-mail and found yourself angrily reaching for the keyboard by the 2nd paragraph, you can appreciate that 99% isn't nearly good enough.

MobileMe (and online data synchronization services in general) are highly effective most of the time. But when there is an unresolvable merge conflict, or when your appointment doesn't get synced to your mobile device in time, or when the service is temporarily offline at exactly the wrong moment, you can get totally screwed. It may only happen 0.2% of the time, but that's all it takes to render the service worse-than-useless.

RAID. I could write a book on everything I hate about RAID. Suffice to say, I consider RAID the premier technology in guaranteeing that any hardware failure becomes a catastrophic, unrecoverable hardware failure. Don't get me wrong, I'm willing to stipulate that most of the time RAID will work just as you'd expect, but the 0.2% of the time that your RAID controller fails, or your RAID configuration gets lost, or something (really anything) other than a single-disk failure rears its ugly head, you are done. And maybe you trusted RAID so much you didn't have a good backup strategy in place. Oops.

Bluetooth on the PC. Even though Bluetooth has always been pretty reliable for cell phone headsets, I can't believe that it's still so outrageously inconsistent on PCs and Macs. You know, scratch that, it's nowhere near 99.8% effective. Still useless though.

Look, this isn't limited to computer stuff. Think about all the things that need to be 100% effective to really, truly work. Car brakes. Mars landers. Twist-off beers. Birth control.

Sometimes good enough really isn't.

I don't lose a whole lot of data, at least compared to many of the people I know or have worked with. I am keenly aware that all hard drives are exactly n seconds away from failure, where n can be anywhere from 1 to something other than 1. So I have backups and I'm careful.

I'm feeling particularly stupid these past couple of days, though, as I've repeatedly had to go back to Time Machine to rescue data that's been blown away for one reason or another.

The most recent incident caused me to lose about 200 GB of personal data, including 6 years worth of photos, my entire music collection, and a number of mission-critical virtual machines in about 3 seconds.

Just thinking about that makes me cringe. It is most certainly easier to destroy than it is to create.

Now, I'm going to go into some technical detail about what happened here, both as a form of self-defensiveness and denial (I swear I didn't do anything wrong), but also as a cautionary tale about the need to respect the command-line in general and rsync in particular. If you don't care about the details I won't be offended if you skip to the last paragraph of this post.

rsync, if you didn't know, is a very powerful and dangerous command-line utility that allows you to synchronize a directory tree between computers. You specify the source folder on a machine somewhere, a destination folder on a machine somewhere, and (provided you have sufficient access to both folders on both machines), rsync will make the destination folder look exactly like the source folder. If you include the (optional) --delete switch, rsync will remove any existing files or folders in the destination folder that are not in the source folder. So you're left with an exact mirror.

The danger, of course, is revealed if you specify an existing destination folder with lots of important stuff, and a completely unrelated source folder with lots of different stuff. In this case, if you happened to include the --delete switch, your entire destination folder would be zapped.

That's why most people are very careful when using rsync, and very very careful when using it with --delete. They make absolutely sure that the destination folder matches the source folder. Most of the time.

I am currently writing a ruby script that automagically synchronizes folders on my production machine with my notebook when I take it out to the coffee shop or whatever to do some work. I can mark the folders I want to take in Finder by changing their label color to red, run my little script, and just the marked folders are copied onto my MacBoook Air. When I'm back, I run the script and my changes are propagated back to my production machine.

Before you ask, I tried using MobileMe and other synchronization options for stuff like this but in the end I found that they didn't work the way I needed them to for one reason or another (perhaps the subject of another blog post) and this simple solution was both exactly what I needed and an excellent excuse to learn Ruby as well. So I wrote a slick little script that depends on the Mac OS X command-line utility xattr to determine whether a particular folder is marked as Red (i.e. to be synced).

When you run xattr -l /Users/(your login name)/Documents/* you will see a list of every folder that has been colored along with some hex data you can parse to determine exactly what color label you used (0C is red, for example). The first line of the output is the name of the folder in question.

My Ruby script parses out the name of the folder and uses it as the target parameter in a subsequent rsync operation. This works great, unless...

There's a bug in xattr. If there is only a single visible folder in your xattr folder, xattr will actually not display the name of the folder at all.

This absolutely must be a bug, because adding a second folder, even a folder with no coloring at all (and therefore not appearing in the xattr output), will resolve this condition. But if there is only a single visible folder, xattr won't show you the folder name.

Needless to say I was not expecting this, and when I ran my script on a folder with exactly one test folder, the destination folder name on my remote (production) machine resolved to (blank) + '/', or the root folder of my production machine's boot drive.

Wow.

So off rsync goes trying to systematically delete everything on the hard drive. Luckily it was running under my user account (and not root), but in the 3 seconds it took me to figure out what was going on and madly punch ctrl-C it still managed to nuke about 200 GB of data.

Time Machine rules. It's the difference between restoring from a static backup (in my case, one that was 3 days old) and a backup that was literally 30 minutes old. RAID would not have helped in the slightest.

The moral of this story is: no matter how smart you think you are, eventually you will do something that seems like exactly the right thing to do but that will wipe out some really, really important stuff. Even if you do everything "right" it's still going to happen to you.

How good are your backups?

Most apps on the Mac launch very quickly. But not all apps. Say you have a big monster app (like Photoshop or Eclipse or something) and it takes a long time to load, with the plug-ins and the recent projects etc. Provided you have enough memory in your machine, you really want that app to stay open for your whole work day. Sure, you can minimize or hide it, but if you're anything like me you've pretty much gotten into the habit of hitting Command-Q whenever you're done with an app, even if you might need it again in 5 minutes.

So here's what I did: I used the Keyboard Shortcuts tool in System Preferences > Keyboard & Mouse to remap the Command-Q key to "Hide (appname)" in my big monster apps, or the ones that I wanted to keep open anyway. Now, whenever I hit Command-Q in those apps they're hidden rather than closed. I can still close them, of course, by choosing Quit from the menu bar. But now, those apps are always a split-second away.

Nice!

About 10 years ago I was developing a commercial application using a 3rd party reporting library and a (separate) 3rd party installer library and I noticed that most of the issues reported by customers had to do with limitations or bugs with those two packages. None of the problems were total showstoppers, but they were just bad enough that customers were annoyed and unhappy and there was no way for us to work around them without dropping the libraries entirely and rolling our own. That's probably the point at which I decided to write GLib.

GLib, not to be confused with any of the public projects or libraries bearing the same name, is a completely internal, personal C++ library that does a Whole Bunch of Stuff (tm). It includes all kinds of basic types like strings, integers, floats, and up, including some neat structures like binary trees and multiple-index lists of arbitrary type. It has a bunch of Win32 specific stuff like windowing, dialog boxes, and audio mixer control. It has SMTP mail support and even some NNTP stuff. It encapsulates Win32 sockets. It has a pretty nice ODBC wrapper. It does SSL and decompresses zip files.

It was a lot of work. Still is, in fact. And it's probably not the best way to tackle certain problems, especially with all the really powerful, productive stuff out there now. But it's my library and I know it very very well. In the (ongoing process) of writing it, I've learned a lot of stuff about a lot of stuff, much more so than if I had cobbled together some Perl scripts here and some Python there and some Rails there. Like my 2nd year Software Engineering prof used to say, writing tools (and, by extension, libraries) is one of the best ways to learn about the environment and programming in general.

A friend recently asked me that, considering 10 years of hindsight and 10 years of open-source libraries and 10 years of changes in the market and the craft of software development, with all that stuff, if I would make the same decision again and build my own libraries from scratch. I've given this some thought, because let me tell you again, it was a lot of work. Not only that, but over time much of the code I put into GLib becomes irrelevant and I yank it, essentially throwing away the initial investment. And it locks much of my development into C++ (because home is where your libraries are). And newer environments really do certain things better. But I've thought about it, Paul, and I would have to say that yes, I stand behind my decision 10 years ago and think it's still the best way to go now. Here's why.

First and foremost, there's what I call the 80% wall. Any 3rd party environment or library will get you only 80% (or 90% or 95% but never 100%) to where you want to be. You'll be cruising along congratulating yourself on how productive you're being and then you'll realize that your SMTP library doesn't support authentication. Or your sockets library doesn't support SSL. Or (heaven help us) parts of your library aren't threadsafe (just the parts that making threadsafe would be hard, of course). Anyway, you get to 80% and you're faced with one of the lousiest possible decisions in artisan software development: do I settle for something that sucks or do I redesign? I hate being in that situation.

With your own library you have ultimate fixability. Anything that sucks you can fix. Anything that's broken, you can fix (or try to). Anything you need to add you can just add. I'm never afraid to step through my code in a debugger and muck with it to see what happens, but working with the guts of other libraries always feels like walking on eggshells because I'm simply not familiar enough with the code to know what's safe to scribble on. Don't get me wrong, I've done my share of hacking other people's code, but I can never be sure that I haven't broken something important in the process. And that's only if you have the source, of course.

Having your own libraries means that you never compromise on design or feature sets. You have the freedom to incorporate the best of what you see in other libraries rather than settling for what some library does great but your chosen library does poorly. It comes down to what problems you want to solve: design problems or integration/debugging problems.

You're insulated from library bloat because you only need to include the stuff you actually use. It's unlikely I'll ever need 90% of what's in .NET so why am I carrying the overhead for it? But I can always code it in if I need to.

With your own libraries you aren't burdened by the obligation to give back to open-source projects or support your changes. If we all actively contributed well written, well tested and well integrated changes to all the open-source projects we consumed then we would not actually get anything done. Don't get me wrong, I believe in giving back but the reality is that much of the stuff I use in GLib is not ready for public (developer) consumption. And that's ok, because it's not being consumed by public developers.

But going back to my original point, writing my own libraries is how I learn stuff. I want to design, not just assemble. I want to understand the internals of the protocols I work with because it makes me better at what I do, and because it gives me a much deeper understanding of my profession. This leads to better insights and (I hope) better designs. Instead of constantly jumping between emerging platforms I am building a base of understanding and capability. And sure, every once in a while I'm a little jealous of what .NET or Rails or whatever can do. But I had ORM in 1999 and hidden-frame asynchronous web interaction in 2001.

We're all trying to build great software. Would you rather design or assemble?

I saw three separate Microsoft announcements today which prove beyond any doubt that there is a massive alien organism systematically eating the brains of everyone in Redmond. I cannot think of any other plausible explanation.

First, we have an abomination of design and common sense they're calling the Veda. I call it the Microsoft Foleo.

Next up, check out Microsoft's name for their just announced GPS offering. "Microsoft Embedded NavReady 2009". I remember when they used to call stuff "Word" and "Windows" and "Project" and "Office." Lately it's been "Windows Live Messenger" and "Windows Mobile for Pocket PC Premium Edition." I can appreciate the desire to cross-brand, but maybe this isn't the way to do it?

And finally, Microsoft authentication rears its ugly head again. This isn't really a Microsoft announcement, but today (in a seemingly unrelated slap in the face), my ISP (Bell Sympatico) blocked their SMTP servers to unauthenticated clients and otherwise changed their configuration in a way that prevented some of my mail from actually being sent. So, navigating the crappy Bell web site (that doesn't work in Safari-- what is it with Canadian telecom providers not hearting Safari?) I had to sign up for several different and completely unnecessary accounts, one of them being a webmail account through Bell, just to find out what the new SMTP settings were. At this point I was pretty annoyed but I almost lost it when I tried to log into the aforementioned webmail account and, lo and behold, was greeted with a Microsoft Live login page. My previously selected login and password didn't work of course, and clicking on Help redirected me from the broken link (naturally) to a generic Microsoft Live login page displayed in a frame obviously sized for something different. Anyway, digressions and angst aside, the fact that Microsoft is still trying to rebrand and sell this crap through distributors like Bell is sad for everyone involved including me.

As a former Microsoft employee, a little part of me dies every time I see something like this happen.

I've always wanted to coin my own acronym and I think this might be my big break.

Have you ever been at a loss for how to gently deflect someone's suggestion for what you should do or how you should do it? Even though you can acknowledge that their suggestion might make some sense and maybe you'll get around to it someday, have you had the feeling that it's really not something you want to get into RFN (right *** now) but you're not sure how best to break the news? Has your boss regaled you with his grand new project idea that's left you nodding, smiling, and slowly backing away towards the exit?

Well here's your snappy comeback. Just tell them that although it's a great idea, it's LITOS. Less Important Than Other Stuff, pronounced like Lite-Brite and Cheetohs.

If you're like me and sometimes have trouble saying no, this is a perfect way to confuse your would-be-delegator just long enough for you to come up with a good excuse, a solid argument, a sharp weapon, or a hasty getaway plan. By the time they ask you what LITOS means, you're well on your way to getting on with your life.

The best part is that you can say it cheerfully and with a big smile, something that's very hard to pull off when saying "No." Try it now. Big grin, "Great idea, but unfortunately it's LITOS." Now shrug like you wish there was something you could do about it, but unfortunately you can't. No-one can. Because it's LITOS.

Now go spread the word. No royalties required, but please give credit where credit is due. And remember: big smile, helpless shrug. LITOS.

Hi, my name is Gene and I use table layouts. I really want to use CSS for positional layout, I really really do. And every few years I look at the various sites I manage and think to myself, Gene, today is the day you replace all this hacky table garbage with nice, clean, browser-independent CSS.

So I scrap the tables and it feels good, like getting rid of accumulated crud always feels. And I start styling. Now, I am by no means a CSS expert and I look up a lot of stuff online and in books, but I now know enough to get around basic grid-like layouts and have figured out the positional properties more or less. And I'm not really doing anything fancy. So, initial progress tends to be quick and in an hour or two I have a pretty sharp, pure-CSS layout working in my test browser (currently Safari).

Encouraged and emboldened I start testing a couple of other browsers that I'd like to support, like IE6 and 7 and Firefox. I notice a few display discrepancies and here is the TSN turning point. This is the exact point at which my CSS journey becomes a death-spiral into whack-a-mole layout hell. I spend 3, 4, 5 hours madly swapping between test browsers trying to figure out why fixing one breaks another ad infinitum.

First I get creative, trying various tricks of cascading styles and divs so that every browser gets fed the kibble they like best. At this point I'm still clinging to the hope that I don't have to use any browser detection nonsense. And for a while it looks like I'm making progress. But inevitably, every single time, one browser will have an unexplained white space between elements that are supposed to be flush or something will wrap where it's obviously not supposed to wrap.

After creativity comes desperation and I start madly trolling the Internet for all kinds of crazy (I'll say it again: crazy) hacks that people use to work around the various browser idiosyncrasies. JavaScript expression syntax, even (OMG I can't believe this exists) conditional JavaScript compilation, and by this point it's about 3:00 AM and I start to ask myself the following question:

How is this horrid, ugly, hack of a CSS layout any more elegant than my original table layout?

Obviously is isn't, so I roll back all my changes and call it a night. Maybe next year things will be different. Maybe by then Microsoft, Apple and the Mozilla foundation will all get together over beers and settle this crap once and for all. And maybe, just maybe, CSS will become as reliable and consistently rendered as my 5+ year old table layout has been. Maybe I'll learn the magic secret of browser-independent CSS and will laugh at the problems I'm facing now. But I doubt it.

Say what you will about CSS vs. tables. At least tables work.

But what specifically do you find useful/better/worthwhile about the Mac platform?

That tends to be what I get asked when I try to justify my recent jump-ship of the whole Windows scene in favour of the Mac. It's a subject that has been rehashed a million times in a million ways and I hate to belabor the point, but it turns out that the answer has some personal elements to it and so maybe it's worthwhile giving a personal answer to an admittedly dead-horse question. And this way I can just point people to this entry (that means you Trevor).

Getting the obvious stuff out of the way first, visually, graphically and in terms of overall user pleasure, Apple nailed it and everything else sucks in varying degrees. You might call it eye candy but I call it the screen I sit in front of for 1/3 of my day (who's kidding who, 1/2). And it makes a difference.

On the Mac I have to deal with less crap. What kind of crap? Many kinds of crap. For example, I have to deal with less legacy crap. If you want to use >3 (that's right, 3) GB of memory in Windows (XP or otherwise), you have to switch to the 64-bit version of the platform and currently, IMO, neither XP 64 or Vista 64 are viable professional production platforms. Half-baked doesn't even begin to describe how I feel about Microsoft's 64-bit efforts.

I have to deal with less driver crap too. Windows users simply can't understand that on the Mac, for the most part, there's no such thing as "installing drivers." You plug something in and it works. There's no device manager notification, no "would you like Windows to check for the latest version of these drivers on the Microsoft web site" (has that actually ever worked for anyone? Ever?) Anyway, when I plugged in my (very proprietary) Plantronics USB headset it worked. When I plugged in my IOGear Bluetooth 2.0 adapter it worked. The only time I ever had to download drivers for anything was for a Wacom tablet, and it actually surprised me that I had to do that. Amazing how fast we start taking things for granted.

The built-in operating system tools on the Mac are light, clean, and (most importantly) sufficient for my needs. I don't need to install Nero because Disk Utility lets me burn CDs and DVDs. I don't need to install True Image because Time Machine works. I don't need to install any Symantec or Norton bloatware because (holding breath) at the moment there is no credible virus or spyware threat on OS X. I don't need to install some crappy fax server software because the built in fax app is sufficient. I don't need to install Firefox or Thunderbird because Safari is fine and Mail.app is also fine for my needs. So I get a simple, unified user experience using 1st party software for the most part.

When I do install other apps, they tend to be of higher overall quality than their Windows counterparts and they also tend to be dirt cheap. I got to stop using Photoshop because Pixelmator is enough for my current needs. NoteBook is awesome (sadly not yet as awesome as OneNote, which I miss bitterly, but oh well). TextMate is awesome and if they just added code-completion I would live my life inside it. All of these incredible apps are like $60 each. Again, Windows users won't appreciate the fact that you can actually do real work using these light-weight apps produced by independent developers: in the Windows world you're typically much better off sticking with the big vendors. Not so on the Mac: there are some real artists doing work here.

I've used my switch to the Mac to lighten up on my app requirements in general. I don't use Office any more, preferring the much more lightweight iWork. Ya, there is stuff I miss (Excel just rocks, or at least it used to until the same guys who thought of the paper clip brought you the ribbon bar). Anyway, by using smaller, lighter applications my load times have gone to effectively 0 and everything just feels snappier and more productive.

And on the subject of snappier: PDF support is baked directly into the OS, and is screamingly, blisteringly, unbelievably and immorally fast. Do not underestimate the value of this. Adobe are you listening? I want every second of my life back that I've spent waiting for Acrobat plug-ins to load.

For all the bitching and moaning in the Mac community, Finder is good. Finder has allowed me to get off the command-line and start moving files and folders around using the UI. The path structure is better (than XP at least), so when I do drop to the command-line I don't have to deal with the difference between Documents and Settings vs. Application Settings.

Safari is good. Safari is fast. Safari is pretty. Safari is sufficient for my needs.

Mail.app is good. Mail.app is fast. Mail.app is pretty. Mail.app is sufficient for my needs (and would be that much more sufficient if it got along a little better with hMailServer, but oh well).

I would be remiss if I didn't mention a thing or two about the developer-specific advantages. I've been known to write a line of code here and there, so developer issues are important to me. And since I target primarily the Windows platform (native C++, .NET, SQL Server, etc.) it may seem counterintuitive that I would want to develop on the Mac. It actually makes perfect sense.

Much of the work I do these days is either inside a VM or against a remote server. Mac has awesome VM options and awesome remote connectivity options. VMWare Fusion is like $80 and is every bit as good (for my needs) as the $400 VMWare Workstation for Windows. Unity mode is awe-inspiring, and actually allows me to use Expose on Windows (sort of, and not without a glitch here and there, but, you know, still). I can't believe that Flip 3D was developed after and in response to Expose. Anyway, the enforced VM mentality forces me to better compartmentalize my work and my projects in much the same way, I imagine, that something like Amazon EC2 forces you to better design your infrastructure from the ground floor.

Real Unix command-line tools. Nuff said.

Anyway, obviously nothing is perfect and I still have to deal with crap on Leopard. As I mentioned, Mail.app doesn't heart my mail server, Apple sort of botched A2DP support in Leopard, my beloved TextMate doesn't do the one thing that would allow me to use it for pretty much everything (namely, CodeSense-style completion), and the other day my Time Capsule needed to be reformatted (exactly the kind of thing you don't want to have to do to your backup drive). But I find myself a lot more tolerant of these glitches because, overall, the experience is intuitive, productive, enjoyable, and FAST. And maybe most important of all, Apple and the community seem to genuinely care about keeping it that way.

I'm not sure whether or how unusual this is, but I tend to look at life from a problem solving perspective. Problem solving has always been a personal strength, and I guess when you've got a big hammer you tend to notice a lot of nails. Of course you can't ever solve all your problems, and there will always be new and bigger problems to solve, and even if you could actually cross everything off your list you'd die of boredom, so having problems is not an inherently bad thing. A key observation is that it's important to be working on the right problems.

What does that mean to you? How do you know if something is a "good" problem or a "bad" problem? That's a tough one, but let's tackle a simpler question: if you're like me and you like solving problems, what kind of problems do you like to solve?

For me, day-to-day happiness is often a question of whether I'm working on problems that make me happy. That's another way of saying "working on stuff that's interesting to me" but it's a little more precise and I'll tell you why.

Vista problems were not, for me, the right problems to be working on. I didn't find them interesting, or fulfilling, or rewarding. Don't get me wrong, I was by and large successful at solving or at least working around almost every Vista issue I encountered since I went production with it in May 2007. But I noticed that the nature, frequency, and sheer stupidity of the issues I was seeing in Vista was making me decidedly unhappy. Not just unhappy, but a little bit embarrassed to be running such a crippled (and crippling) OS.

So I switched. After almost 20 years of running Windows as my production OS I've switched to OS X. I still run a number of XP VMs using VMWare Fusion, and even a Vista VM for testing, so I'm gradually moving decades of personal and business data over to the world of Mac. In addition to my production OS X desktop (which has the exact same specs as my production Vista box but feels oh-so-much-faster), I just picked up a MacBook Air for on-the-road work and it is just a breathtaking, out-of-the park design triumph for its intended purpose.

It hasn't been a completely seamless transition and yes, there have been problems. But they've been good problems and I've enjoyed working on them. And so far, knock on wood, no regrets.

Today (Monday) my accounting system stopped working. It was fine on Friday, and as far as I know there weren't any Windows updates or other configuration changes over the weekend. But today, when I start QuickBooks 2007 Pro (Canadian) I get a QuickBooks has encountered a problem and needs to close. We're sorry for this inconvenience.

Call me a cynic, but I'm not feeling their their sorrow.

I'm writing this entry as I try to resolve the issue. A quick web search has uncovered a large number of known Vista-related bugs with QuickBooks (and expecially QuickBooks running on Vista 64) but not only have I known about these, I've actually worked around them already. In fact, my QuickBooks installation has been limping along quite nicely for several months now. Until today of course.

Sure, every once in a while I need to kill the splwow64.exe process from Task Manager just so that I can print a document, but I've swallowed my pride and decided that I've got better things to do than completely swap-out my accounting system just to quell my annoyance.

So the first thing I suspected was that something got bashed with my company file and I moved it so that QuickBooks would have to prompt me to use the sample data or whatever. No change in behaviour. Then I suspected the QuickBooks configuration might have gotten corrupted so I messed around with QBW.ini for a while, eventually removing it altogether, just to see if I could get past that error. No dice.

A complete re-install of the QuickBooks application did not help either. Before and after applying the latest patches, QuickBooks still died immediately upon startup. Clearly something magical happened this weekend to either my machine or to the QuickBooks software.

So what can we take away from this experience? Let's just say, for the sake of argument, that Vista shipped before it was 100% perfect. I know, I know, hard to believe, but bear with me for a minute. Let's say that Microsoft (and many other software companies) ship at 90% and let the inertia of real customers, partners, developers, etc. drive their quality level up over time through patches, updates, and so forth. I actually don't have a problem with this strategy, because if everybody waited to get to 100% before shipping (and generating revenue) we would have a lot less software choice than we currently enjoy.

Anyway, Vista ships before it's 100% perfect on the assumption that developers and customers will jump on board, get excited about the platform and drive the smoothing process. But here we are, almost a year later, and the only jumping on board has been reluctant and (in some cases) regretful. Intuit, the major player in the small business accounting space, has yet to release a fully Vista compliant version of QuickBooks. Palm has yet to release a (non-beta) version of their sync software. These are not marginal players here: both Intuit and Palm have an installed base in the millions, I would imagine.

What effect must this have on the morale down in Redmond? Vista is getting panned from almost every direction and even Microsoft's historically loyal developer base is dragging its feet. Significant numbers are either holding off for now or actively researching alternatives. Linux and especially Apple are both reaping the rewards as Microsoft madly scurries to recover their fumble.

Wait a second. Madly scurrying? Where?

I see a surprising lack of mad scurrying. Historically, Microsoft has been exceptionally good at fixing mistakes and moving forward. Didn't they like invent the service pack or something? They certainly made it OK to ship less-than-perfect software on the assumption that it will be fixed later. And so we wait. But now Microsoft is telling us that Vista Service Pack 1 is going to be no big deal, and that most of the included fixes have already been rolled out through Windows Updates. But I still need to periodically uninstall my DVD-ROM drive and let Windows re-detect it before I can even play a DVD (another known issue).

What's my point? With no evidence other than observation, I think the folks in Redmond are demoralized and frustrated at the lack of Vista uptake and, rather than translating this into nervous energy and solving the problem, they are getting lethargic and possibly punch-drunk. They continue to make bad decisions: everything from second-rate UI (compare Flip3D to Expose/Spaces), nasty compatibility hacks (registry virtualization in Vista), even marketing (Windows Live? The Social?).

The transition to 64-bit is a clarifying example. When Apple moved to full 64-bit-ness in Leopard, nobody noticed. Microsoft has been straddling the fence on 64-bit compatibility since XP 64-bit (maybe even earlier) and they still haven't gotten it right. Why oh why oh why do I need a separate Program Files and Program Files (x86) folder? Why must I use 32-bit IE7 on my 64-bit machine because my 3rd party browser extension of choice (Roboform) isn't available in a 64-bit binary? These are the questions that I ponder as a Vista 64 user.

The stakes are high. There is a tipping point at which people will once again feel that they have a real choice in operating systems: it will no longer be absolutely necessary to deploy Windows due to backwards compatibility. Some will argue that we've already reached that point, but I don't think we're there just yet. We will be soon though.

Isn't Palm to blame here? Isn't Intuit to blame for not adequately preparing, adequately testing, adequately modifying their software, especially since they had so much advance notice of Vista? Maybe, but I think that their culpability is limited by the fact that it was Microsoft's responsbility to demonstrate that they should divert sufficient resources to make those things happen. Ultimately, hey weren't sold on Vista any more effectively than the rest of the user and developer community. So now everyone suffers.

So what about my current QuickBooks frustration? It looks like I'm stuck running QuickBooks in an XP VM for now. Hey, couldn't I do that exact same thing using Linux or a Mac?

Yes, yes I could.

The fact that Microsoft deploys Windows Genuine Advantage Notification (as a strictly self-serving anti-piracy measure) through its own automated update pipe is annoying enough. The fact that they upgrade it constantly and continue to force out updates, littering my Select Updates page (and the Select Updates page of each of the various VMs I manage) is just plain insulting.

I was recently researching a ridiculously obscure JavaScript behaviour in Safari that was causing problems with our AJAX-y web app. I found the answer on Google within 1 minute in the top 10 search search results. I'm not going to belabor the details of the issue itself (it's here if you're interested), but if someone hadn't put this information online or if I couldn't somehow query it I would have probably lost weeks of my productivity resolving it. This is a very old story, but if you add up the weeks I saved and the weeks you saved and the weeks everyone saves every year by having the kind of access to information that we all have, instantly, everywhere, you start understanding Google's $200B market cap.

When I first installed Vista on my production machine in May 2007 I didn't realize just how much of an early adopter I was. Now, about 7 months later, I think I've got it running with sufficient perkiness that seeing the comparative responsiveness of a 4 year-old XP box doesn't make me (too) jealous. Before moving to Vista I bought a BBB (big bad box) for the project, including a quad-core processor, 4 GB of RAM, nice fast disks and graphics card, and so on. But only now does Vista officially Not Suck That Bad for me. Here's all the stuff I did, roughly in descending order of perceived performance impact. This is pretty subjective, so start at the top of the list and work your way down, turning stuff you really like back on and seeing what you think.

Turn off system restore (and shadow copy by consequence). Constant disk thrashing feels particularly unempowering to me.

Turn on write-back caching if you have a RAID-5 array. This basically guarantees the demise of your data if you don't have good power back up, so make sure you have good power back up. RAID 5 is absolutely unusable without write-back caching.

In Control Panel, System, Advanced System Settings, Performance, Settings, turn off Animate windows when minimizing and maximizing and Fade or slide menus into view. Yes, these are highly accelerated graphics effects and yes, they make Vista look very cool but I can't stand waiting for a visual effect when a window or menu is opening. I actually like the effect when windows are closing, which is why I'm so frustrated that the first of these options isn't split into separate 'minimizing' and 'maximizing' checkboxes. But for me, having application windows snap open instantly goes a long way to making Vista feel usable.

Get a good graphics card if you don't already have one. I have 2 monitors which I run at 1920 x 1200 each, and a 7600GS wasn't cutting it. My new 8800GT is much nicer. Glass is purdy.

UAC popups are unforgivably disruptive because they occur on the secure desktop. With the large screens I just described, I could wait a second or two staring at a black screen before the damn thing even came up. It's a major security no-no, but you can have the UAC dialog open on your regular (non-secure) desktop by following the instructions here. This isn't as bad (security-wise) as turning off UAC altogether, which I was about 2 seconds from doing.

If you use IMAP, your mail client of choice is now Thunderbird. Windows Mail is simply too slow.

If you use IE7, increase your HTTP connection limits ala this MS KB artcile. This won't make IE7 fast, but it will make it a little less slow.

The more perceptive (cynical?) among you might look at all the stuff I turned off and realize that I'm back to a very XP-like feature set. To this point I can only sigh, shrug, weep a little maybe, and get on with life. I did at one point turn off indexing service and defender but have since turned them back on. I had to draw the line somewhere, if only to prevent myself from reformatting and moving back to XP.

Today I needed to quickly set up an IIS7 service on Vista and get it running a legacy ASP web site. This is something that should have taken about 10 minutes, but it did not. In fact, it was an embarassingly painful experience that almost ended in bloodshed when Vista froze on my laptop and I did the 4-second countdown on the power button. Anyway, here are all the things that, had I known/remembered them, would have averted the drama. Well, almost, because the freeze is still unexplained (unless you're just expecting Vista to freeze every once in a while, 'cause that's what it does).

When you install IIS7 on Vista, you must explicitly include ASP, ASP.NET, CGI, and whatever else you want. IIS7 takes a minimum-footprint approach (or, more precisely, a minimum attack-surface approach) so it won't install these things for you by default. Review your options carefully before OK'ing the install.

If you have ASP pages on your site you need to Add Application, not Add Virtual Directory. And don't even bother trying to put stuff into the root of the Default Web Site.

If you're doing this on a laptop and your IP address changes somewhere mid-stream, restart the World Wide Web Publishing Service (w3svc). IIS7 doesn't seem to adapt to a changing IP address very well.

If your site needs parent paths, explicitly include them in the ASP configuration for your app. By default IIS7 disables parent paths.

Give IUSR and NETWORK SERVICE Read, List Directory Contents, and Execute permissions on your directory and all sub-directories. You may not need NETWORK SERVICE, but I seem to.

And here's the one that makes this whole entry worthwhile: the Edit Anonymous Authentication Credentials dialog box in IIS Manager seems to be capital-B Broken. Any time I changed the installed components of IIS7 (including after the initial installation), Vista "forgot" that my default anonymous user was set to IUSR and every request to every page returned with 500.0 Internal Server Error (0x80070005 - access denied). Every time I added or removed IIS components I had to do the Anonymous User Dance: set the anonymous user to something else, apply, set it back to IUSR, apply.

A suggested general approach: start with a trivial test.htm file in the root folder of your app's directory. Once you can get the test.htm file to show up move up to a trivial test.asp page. When you can get the test.asp page going, you should be in good shape.

Anybody who spends a non-trivial part of their life troubleshooting computer issues knows that a seemingly inocuous annoyance can often (surprisingly often) spiral down, slowly at first and then with increasing momentum, into the very depths of computer hell. This happened to me today, and I blame StickyKeys.

StickyKeys is an accessibility feature for Windows that has been around since Win2K I think or maybe even earlier. It's supposed to help people who have trouble using the keyboard by "holding down" a key when the user can't do so themselves. I'm not actually 100% certain of what it does because, and this is important, most people never need or want StickyKeys. Windows, however, has a built-in shortcut to enable StickyKeys that (I imagine) most people will accidentally trigger at some point.

In fact, you can try it yourself: tap the Shift key rapidly about 5 times. Voila: StickyKeys.

So anyway, I was playing a little Splinter Cell and, in a futile attempt to jump onto a ledge I accidentally enabled StickyKeys. Splinter Cell, being a 4 year old game, isn't the most well-behaved application in Vista and between trying to complete my ill-fated acrobatics, switching back to the Windows desktop to tell me all about the StickyKeys I had just enabled, and (coincidentally) the RAID disk rebuild that had been going on for about 5 hours at this point with no end in sight (don't ask), Vista became about 99% unresponsive. I say 99% because I was actually able to shell a command-prompt and kill the SplinterCell.exe process and explorer.exe, and just as I was celebrating my ingenuity as Explorer started reloading, Vista blue-screened with a page lock exception.

Now, keep in mind that my RAID rebuild was still in progress, and if there's one time you don't want to blue screen, it's when your disk array is being rebuilt (well, that and when your firmware is being upgraded, but that's another story). Needless to say I was a little concerned. Happily, the machine rebooted normally and the rebuild picked up from where it left off. 7 hours in and at about 20%. Sigh.

Happily there hasn't been that much fallout from my shotgun upgrade to Asterisk 1.4.11 a few weeks ago. I'm still not satisfied with the latency I'm getting from the new setup, and I started noticing that incoming DTMF wasn't being detected properly. If a caller entered their DTMF slowly and deliberately everything worked fine, but if they punched out an extension as fast as their little fingers could, Asterisk failed to accurately interpret the entry. This caused much pulling of the hair as, with IAX2 channels, there really isn't all that much that can (or should) go wrong with DTMF signalling. Tones are transmitted as single data frames (not audio frames) so they should just be picked up by Asterisk in the order they were entered. If only things were that simple. Anyway, to cut to the punchline, I had to change 2 constants defined in channel.c to get DTMF detection working perfectly again. These changes will more-than-likely mess up DTMF detection for non-IAX2 channels, so if you use SIP or something else that transmits DTMF as tones you should probably proceed with caution. But if you're IAX2-only and having DTMF detection issues, try this:

#define AST_DEFAULT_EMULATE_DTMF_DURATION 0

#define AST_MIN_DTMF_GAP 0

(to replace the existing constants of course)

As a comical (in a sad clown way) aside, I actually tried upgrading to Asterisk 1.4.13 hoping that would solve both my DTMF and latency concerns. No dice: it segfaulted consistently within 30 seconds of startup. The response to my question about this on #asterisk? "Why would you want to run Asterisk on a Mac?" Why indeed.

One thing you'll never do after switching to VoIP is take your telephony for granted. Like for example, when your service provider innocently upgrades their Asterisk servers from 1.4.9 to 1.4.11 and inadvertently breaks your complete 1.0.10 installation, you may find yourself swimming in self-doubt about your decision to go to VoIP in the first place. You may ask questions like, "why am I spending all this time customizing and troubleshooting a setup that was working perfectly well until, essentially, reality shifted out from under it? And you may realize that current information technology is really a set of shifting platforms that your itty bitty solution needs to constantly jump between to keep from falling off completely.

Ok, enough navel gazing. My VoIP provider upgraded, it stopped my setup cold, and that weekend and the subsequent two weeks were spent.

* Upgrading to the Mezzo pre-built Mac OS X binaries of Asterisk 1.4

* Figuring out that these were hopelessly inadequate for my needs, and not just because of the frequent seg faults, but because I actually need source code in order to put back the various hacks I've written about and still haven't been addressed for real in Asterisk. I really need to get around and contribute this to the project, if only to save myself the time of re-hacking Asterisk the next time I'm forced to upgrade.

* Installing the 1.4.11 source, building it, and re-applying my crude workaround hacks

* Rewriting my softphone

This last one was the most time consuming by far, and even though it wasn't strictly (or really at all) necessary to work with the new Asterisk, I did it anyway. I decided that my softphone belongs on main production machine from now on because having a console media app running on my network file server was just too ugly to bear. Also. these days my production machine is big and burly enough to handle a little real-time VoIP while still building a commercial software application, burning a DVD, and maybe playing a little WoW at the same time. Which of course meant re-writing the softphone for Vista, and throwing away (with much wringing of the hands) the slick MediaPad integration I had so painstakingly built up because the integration layer I was using wasn't (surprise surprise) Vista compatible.

I'm now using the awesome X-Keys Pro programmable keyboard and Vista's Raw Input functionality, but it's got its ups and downs. First, as nice as the X-Keys thingy is, it's not as svelte as the MediaPad and the lack of LCD means I have to include UI on my desktop to see what's going on with my phone. Second, it's tethered to the machine and glad as I am to be rid of Logitech's Bluetooth-but-not-really approach to wireless input, now I really have to stay close to the machine in order to make and receive calls even though the headset itself is completely and blissfully wireless.

The positives: it's got more buttons, which means I can have volume up and down for both the mic and the speaker, and I can have 3 lines instead of 2, and I can have speed dial buttons so I can accidentally speed-dial my brother's cell phone in the middle of the night, and I've got tons of other buttons left over for fun non-phone things that I'm only starting to imagine. I wonder if, using a keyboard macro only, I can get a pizza delivered with one button push? A worthy challenge for some other time. Anyway, the clincher in favor of the X-Keys was that I didn't need to have num-lock on in order to use it.

I could write a substantial rant on this point alone, but suffice to say that in order to use the Logitech MediaPad for something other than its intended purpose, you need to leave your keyboard in num-lock ON (which I hate) and the softphone (or your intended target application) needs to have keyboard focus whenever you send it input. This only worked for me before because I had the softphone running on an otherwise hands off server machine, so I could afford to keep num-lock on and lock input focus on the softphone. On my production machine that was a no go, so hello X-Keys.

Even that was a little more difficult than I imagined. I figured I would program every X-Key with a crazy chord like Win-Ctrl-Alt-Shift-S, Win-Ctrl-Alt-Shift-T, etc. Something that no other application in the universe would listen for, and then I would have my app listen for it. Moreover, my app would only respond to it if it specifically came from the X-Keys keyboard (Raw Input lets you differentiate between actual physical keyboards). Perfect right? Well it turns out that some apps actually listen for EVERYTHING. Photoshop is a great example. I kid you not, Win-Ctrl-Alt-Shift-S will actually open "Save For Web" in Photoshop CS2. Anyway, at the moment I'm prepared to deal with this because everything else is pretty smooth.

So what we have now is a 3-line IAX softphone running on Vista, taking keyboard input from a X-Keys Pro, and driving a Plantronics CS50 USB headset for audio. Photos and screenshots to come.

One of the really unfortunate things about writing a custom IAX softphone rather than just using an industry-standard SIP softphone is that you don't get the three-way calling capabilities that seem so default in the SIP world. In fact, the iaxclient library that my IAX softphone is based on (as well as many of the other IAX clients you'll find out there) doesn't yet support multiple active connections at the same time. I'm actually toying with the idea of trying to build it into the library, but to be honest I think that this is one of the things I have to back slowly away from before I hurt myself.

Anyway, the consequence of not having 3-way calling is that I spend a lot of time using freeconference.com (which, by the way, is just stellar). If you're not familiar with freeconference, it's a U.S. based absolutely free conference bridge that allows you to tele-conference for the price of a long-distance telephone call to the mid-western states. Now, I'm on a VoIP line so my cost to participate in this teleconference is like a penny a minute but the other participants usually have to pay the going rate to take part. This isn't a big deal but it does cross my tolerance threshold every once in a while, like when there are 3 or more participants in local Toronto all dialing in to the U.S.

Long story slightly shorter, I wanted my own conference bridge and (hooray) Asterisk has one built-in called MeetMe. MeetMe has two major drawbacks: 1) it's the mother of all conference bridges, with DTMF commands for kicking people out, kicking people in, kicking people in the ass, you get the idea. It's a little overkill. And, more seriously, it (at least ostensibly) requires Digium timing hardware (ala a Digium voice-board) that, to the best of my knowledge, is not even supported on the Mac yet.

To the rescue comes app_conference, a lightweight conference bridge brought to you by the same people who wrote the iaxclient library itself (these guys rock). It's dead easy to use once it has been set up, but there of course is the rub. Very briefly, here's what you need to do to get app_conference working on your Mac Asterisk 1.0.x.

Step 1: upgrade your Xcode environment. You were planning on doing this eventually so might as well do it now. What's a 1 GB download to you anyway?

Step 2: install SubVersion and (optionally) a nice GUI front-end. I used Martin Ott's pre-packaged binaries and the svnX GUI for Mac OS X.

Step 3: check out the current app_conference tree from SourceForge here: https://appconference.svn.sourceforge.net/svnroot/appconference. They used to use CVS but now they use SubVersion so you can safely disregard any other web instructions you see that reference CVS.

Step 4: ignore the trunk folder because that is for people who actually use Asterisk 1.2 or later. You, lucky Mac owner, are stuck on Asterisk 1.0.x so you need the app_conference that is in the branches/1.0 folder. Follow the instructions in the Compiling app_conference section of this page to tweak the code slightly.

Step 5: (learned the hard way) there are a couple of additional tweaks before you can actually build it. In the Makefile you need to change the paths at the top to reflect your build and deployment environment. Then change the app_conference.so rule to $(CC) -pg $(SOLINK) -o $@ $(OBJS) because (it appears) somebody forgot to replace a hardcoded set of parameters with $(SOLINK). And here's what cost me a morning of my life that I will never get back: you also need to comment out this line:

		CFLAGS += -mcpu=7450 -faltivec -mabi=altivec -mdynamic-no-pic
		

to avoid the dreaded local relocation entries in non-writable section errors. The Makefile says that these flags are "fun for PPC" but I assure you that they are not. Naturally comment out the "fun for x86" line as well.

Step 6: Do the make dance: make clean, then make, then make install. Hold your breath as you see compiler warnings filling your screen, silently praying to yourself that it doesn't really matter and it will all just work. Isn't -Wall wonderful?

Step 7: Now mess around with your dialplan (extensions.conf) to add the conference support you want. You can follow the example here or do anything else you'd like (I chose to hardcode a particular extension as our "conference room"). Try it out. If it works, pause for a moment to reflect at the magic of VoIP technology. If it doesn't work, I wish you good luck.

This problem will probably go away when Creative gets around to fixing it in the next driver release, but in the meantime, if this bugs you (because it bugs the hell out of me), put my nifty little 3 KB solution in your Startup folder and watch your problems disappear. I've even posted the source code so that you can satisfy yourself that this isn't going to reformat your hard drive or anything. Having said that, no promises that this fix is going to work for you as I've hardcoded the control ID of the little Digital Out checkbox and I have no idea whether the ID varies between driver versions, card revisions, etc. For what it's worth, I've got the X-Fi ExtremeMusic.

If you use Microsoft Visual Studio you can build the executable yourself using this command:

cl /MD fixdigout.cpp /link wimm.lib

Another thing to remember: since this is going into your Startup folder this won't actually do anything until you log in (and the stuff in Startup actually gets executed). If you absolutely must have this fix in place PRIOR to logging in (like when the machine starts up and waits for you to hit Ctrl-Alt-Del) you need to look into running this as a service or scheduling it or something. I'll leave that to your imagination.

All this program does is use the Windows Mixer API to (effectively) uncheck and then re-check the Digital Output setting for the X-Fi. This nudges whatever needs to be nudged to turn Digital Output back on after a system reboot.

Please enjoy and good luck. As always, no promises or guarantees but it works great for me!

Ugh. Well, troubleshooting an issue with the voicemail MP3 functionality I hacked into Asterisk a few months back quickly made me realize that with Linux, it's impossible to remember anything and you have to make a note of everything just to be able to recompile the damn thing, let alone actually solve your original problem. So, for my reference and yours (if you've been scratching your head as to how to compile app_voicemail.c or any other Asterisk module, here are some important pieces of information. These, of course, apply to my own configuration but chances are that yours is close.

First, paths. app_voicemail.c and all the other source files (and .so object files) live in /usr/src/asterisk/apps. To compile them, run make from the /usr/src/asterisk directory. Trying to run make from the apps directory itself will not work. After you've run make you have a bright shiny app_voicemail.so file for you to move into your production modules folder, namely /usr/lib/asterisk/modules. Naturally you will want to cycle asterisk while doing this.

And now you should be all set.

So you're tired of the unable to transfer message you get at the Asterisk console when your call is between a softphone behind the NAT and a VoIP provider outside of the NAT. The call still works of course, but it chafes you that Asterisk is routing packets between the two endpoints when really it has no business being involved after the call has been established. You want a pure transfer with Asterisk taking itself out of the media stream, either to reduce latency on the call or to conserve load on the PBX box. You are right to want these things. I wanted these things too, and I got them. But it wasn't easy.

Asterisk, or at least the 1.0.10 build I use, transmits a client's internal address to the outside party when attempting to initiate a transfer. This does not help you because your outside party will attempt to reach the client using this internal address and fail. IP address 10.0.0.25 (or whatever) does not actually mean anything outside your network and your outside party will not be able to directly communicate with your softphone, thereby putting the kybosh on your transfer and relegating you into the (slightly but noticeably) higher-latency world of native bridging. But you're damned if you're going to settle for that nonsense: you can hack Asterisk so that it determines if clients are on your own local network and rewrites the transmit request so that the external address + the unique client port number is sent to the outside party instead.

After the hacks detailed below, each of your softphones will be assigned a unique UDP port and that port will be forwarded from your router to the correct machine inside your LAN.

First, we need to find a way to bind each of our softphones to a different, unique, non-default (4569) port, and then tweak Asterisk to, during a transfer attempt, communicate each client's external address rather than its internal one (so that the outside call can reach the client via the NAT router).

Life can be surprisingly difficult sometimes, and each of these steps certainly is. First, binding a softphone to a non-default IP address can be a challenge if your IAX softphone doesn't allow you to configure your bind port. Note that this is not the same as registering on a server that is listening on a non-default port (you can often do this by appending a :portnumber to the hostname when specifying your account information). What you want is for your softphone client to actually listen on a different port, and that is a whole different story. You either need a softphone that allows you to specify the bindport (don't ask me, I don't have one) or, if you're like me and are using an open-source IAX softphone written using the iaxclient library, you can simply hack the code to get this done.

Until recently you would have had to hack both the iaxclient library and the softphone client itself (I use iaxcomm). Luckily, recent updates to iaxclient now allow your softphone to set the bind port. Here is the sample hack to the IAXComm softphone to bind to port 4570 (as an example).

in iaxcomm's main.cc, add the following line immediately before the call to iaxc_initialize:

	iaxc_set_preferred_source_udp_port(4570);

Now of course you shouldn't really hardcode this, especially since every softphone on your network will need its own unique UDP port. Do yourself a favour and figure out how to make this a parameter you can pass somewhere, maybe via the registry or as a command-line parameter to your softphone.

Rebuild the softphone and this part is good to go. The new port will be transmitted to your Asterisk server during registration and you shouldn't notice any difference in softphone operation.

When assigning unique port numbers to each of your clients you might want to use a convention that includes the client's internal extension number (for example 10xxx where xxx is the 3 digit extension) to improve manageability of your numbering system. But hey, its up to you.

Ok, now we scribble over Asterisk. As I said, you need Asterisk to determine whether a transfer attempt will try to traverse your NAT router and, if so, rewrite the internal client's IP information in the transfer request to use the NAT router's external IP + the client's unique port number. All of this is done in the iax2_start_stransfer function in /src/asterisk/channels/chan_iax2.c.

Note that this hack is currently hardcoded to treat any 10.x.x.x network as internal. If you use 192.168.x.x or whatever you will need to modify this code. Also, this is NOT the way to parse and compare IP addresses. Use at your own risk. Having said all that, here is the complete, modified iax2_start_transfer function that I use:

http://www.timetiger.com/gene/bluevoice/iax2_start_transfer.c

As you can see, I've really taken shortcuts on processing the IP addresses to make the NAT/no NAT determination and this could be improved. Also, this code depends on the username of your VoIP account to match its host name (the one inside the square brackets in your iax.conf file).

Finally, you will need to port-forward each of your assigned UDP ports from your router to the correct machines. Once you've completed this step, you should have native transfers working great.

Well, great might be a strong word, because you might run into the problem I ran into: the jitterbuffer implementation in iaxclient doesn't seem to work very well after a native transfer, at least for me, and I would intermittently get one-way audio after a transfer. I had to completely disable both the new and the old jitterbuffers in order to get decent, reliable audio Here's what to do:

First, in the Makefile for the iaxclient library, set USE_NEWJB = 0 (the default is 1). This will disable the new jitterbuffer.

Now, you have to disable the old jitterbuffer. This is done in the libiax2 source, where you must scribble on iax.c and change the appropriate line as follows:

	static int iax_use_jitterbuffer = 0;

If you are an IAXComm, iaxclient, or libiax2 developer please don't scream at me for scribbling all over your hard work. I am working to make these hacks more robust and will contribute what I can to the projects.

This should do the trick, although you may still experience a slight hiccup a second or two into each phone call as the transfer from Asterisk to your softphone takes place. If something doesn't quite work for you, here are your new favorite Asterisk CLI commands:

• iax2 show registry
• iax2 show channels
• iax2 debug
• iax2 no debug

If you're really confused and want to understand the transfer process from the inside out install a packet analyzer like Ethereal (which knows all about IAX2 traffic) on both your Asterisk box and your internal softphone box and start studying.

Good luck!

For such an incredibly simple and powerful voice-mail system as the one built into Asterisk, it seems odd to me that a message sent as an e-mail attachment must be sent in either WAV or WAV49 format. As far as I'm concerned we live in an MP3 world and when I pick up my v-mail on my smartphone I don't want to wait for minutes for a single message to download. I searched at some length for someone who has already solved this problem but I wasn't able to find anything so I just hacked app_voicemail.c to forcibly convert voice-mail WAV attachments to MP3 before sending. It isn't pretty but if you want it please feel free to grab it here:

http://www.timetiger.com/gene/bluevoice/app_voicemail.c

It has been a busy few months for the BlueVoice project. After my unadulterated disgust with all things Bluetooth (well, actually, it's working quite well with my cell phone but I refuse to have anything to do with Bluetooth/PC), I've decided to experiment with some of the fantastic cordless USB headsets that Plantronics has released. I picked up a CS50-USB and I have to say I'm blown away by how smooth the experience has been so far, especially when compared with my Bluetooth debacle. There has been a flurry of BlueVoice development activity, including a complete move to VoIP technology, and here's what the system architecture looks like so far:

The BlueVoice application is the main integration piece. This is a custom windows application that manages the interactions between all the other pieces (described below).

The Asterisk server, which is running on my shiny new Mac Mini, provides a VoIP PBX and handles voice-mail and auto-attendant functionality.

The IAXComm softphone, based on the open-source iaxclient library, handles actual voice communications.

The Logitech Mediapad, customized as a phone controller using a great DLL made available by Cyberdevil here:

http://www.vbfrance.com/codes/CONTROLER-VOTRE-PC-AVEC-VOTRE-MEDIAPAD-LOGITECH_30593.aspx

The Plantronics CS50-USB headset, providing the actual voice interface to the system.

Microsoft's Speech API, that currently does some simple text-to-speech to provide call status over the headset but will probably be extended to support voice-dialing and other voice features.

I think that, for the time being, I am going to shelve the work I've been doing on a Bluetooth headset/telephone solution. This is a summary of where I went on this project, not so much as a cautionary tale, but more to give you a sense of just how far this technology has to go.

The objective was to come up with a cordless telephony solution that allowed me to use an arbitrary Bluetooth headset to make and receive POTS telephone calls. I needed good to great sound quality and a seamless user experience comparable to using a traditional corded headset. I wanted to see whether I could use Bluetooth technology to implement this vision.

I started with the Sonorix headset, dongle and Bluesoleil stack software that my friend Garth provided. This was a non-starter because the pre-release hardware, when combined with the early version software, was unusably buggy. Later versions of the Bluesoleil stack did not work with the pre-release dongle because the dongle wasn't licensed for the newer versions of the stack, which leads us to the first dumbass Bluetooth problem: licensing limitations between software stacks and dongles make it difficult to try different things to get something to work. Sonorix offered to upgrade the headset, dongle and software to the latest version for US$180 + shipping but I decided to continue investigating elsewhere.

I picked up a Linksys Bluetooth dongle from Canada Computers, which works with a recent version of the Widcomm stack, an altogether more friendly animal than the old Bluesoleil stuff. Having said that, The Widcomm stack doesn't support all the cool streaming audio supported by the Bluesoleil stack, whcih leads us to dumbass Bluetooth problem #2: it's too easy to buy a product that doesn't support all the profiles you need. The Microsoft stack, built into Windows XP SP2, supports virtually no useful profiles at all, which gives us Bluetooth problem #3: little or no publicly available (cheap) Windows SDK support for writing Bluetooth software. But I have a theory about this: Microsoft doesn't want to get anywhere near Bluetooth because it's so hard to write a stable SDK against a moving and unstable target. I don't blame MS for not wanting to get involved (Apple seems to have managed to succeed here though).

Moving right along, playing with my Linksys dongle and Bluetooth stack I was able to connect to the Sonorix headset and get SOME of the functionality to work. Dumbass Bluetooth problem #4: profile support is inconsistent between implementations. But regardless, I was able to use the Bluetooth Audio device in Windows sound manager to play back and record sounds using the Bluetooth headset.

My next step was to try and bridge that Bluetooth Audio device with a POTS line. The most direct, inexpensive mechanism I could find for doing this was an old Windows Voice modem, which provides a similar Windows sound manager device as the Bluetooth Audio device provided by the dongle/stack. I picked one up on eBay for like $5 or something and installed it with no problem. Unfortunately, even though the modem had the all-important full-duplex speakerphone capability that is required for the application I was attempting, Windows itself only provides a HALF-duplex interface to Voice modems. They never bothered implementing a full-duplex Voice-modem interface into Unimodem V. I found this out the hard way, after having written a prototype DirectSound bridge in C++ to try to bridge the two audio devices. There is of course no way of doing this through the built in Windows Audio UI and I could not find any existing software to achieve this effect.

This is probably for the best, because even if I could have written a low-latency full-duplex audio bridge between the voice-modem and the Bluetooth Audio device, I would have likely been faced with the following:

• poor audio quality due to the design of Bluetooth headsets, which are engineered for mobile use and do not, as a rule, provide the same fidelity that a professional CSR-type headset provides.
• poor audio quality due to latency. We have latency from the headset to the dongle, from the dongle through the bridge, and from the bridge through the voice modem to the POTS line. I'm not sure how bad this would have been, but it probably would have sucked.
• poor audio quality because of the voice modem. I've read several unencouraging articles about the actual voice quality over a voice modem. This could have been mitigated by buying a professional POTS interface board, but that option is described later in this note.

So, I decided to drop this for now. From what I can tell, the best vector for further work would be, as my friend Paul suggested, to set up an Asterisk server (a Linux-based open-source PBX which can be integrated using a $100 interface board to a POTS and natively supports digital audio devices such as Bluetooth headsets). This would require dedicating a Linux box to this function, as well as rewriting/scrapping my existing custom Auto-attendant application in favour of an Asterisk-based one. Alternatively, I could go fully VoIP, which against means scrapping my existing auto-attendant as well as a pretty good service configuration (not to mention contract) we have with Bell in favour of what's behind door #3. Finally, there are now several commercial products in the C$500 range, notably by Uniden and GN Netcomm, that are designed to be bridges between POTS and Bluetooth handsets/headsets. These are promising, however would continue to suffer from audio problems related to the mobile design of BT headsets as well as dumbass Bluetooth problem #5 (I think we're at #5 now): Bluetooth 1.1 (which the Uniden and GN products support) devices operate in the same frequency band as 2.4 GHz cell phones and 802.11b and g wireless networks. Apparently BT 1.2 devices use a frequency hopping approach that mitigates this problem, but right now operating BlueTooth 1.1 devices in the same place as a wireless router is an excercise in frustration.

And that's where we're at folks. My current solution is a $60 cordless headset telephone made by GE and sold at Staples, and a $30 RadioShack headset w/ noise cancelling gooseneck mic that sounds better than any mobile headset I've used to date. Believe me when I say it's not pretty, but it works. Which is of course more than can be said for the Bluetooth stuff.

It all started easily enough. I spend a lot of time on the phone, both at home and especially as part of my job, and conventional telephone headset systems were never satisfactory to me. Cordless phones with corded headsets were almost as bad as being tethered to my desk with a corded headset, and the very few fully cordless headset systems out there were all broken in one way or another (two words: handset lifter). Anyway, I decided that there must be a better way and set about finding it.

The original BlueVoice vision was for a Bluetooth headset connected to a computer which was then interfaced with a regular telephone line. Calls could be answered and conversations could be held using the Bluetooth headset, and the possiblity of voice-activated dialing and other call management functions through the headset were a scintillating possibility.

The first hurdles were substantial, but over time, the vision evolved...