The next version of Songbird (0.2.5) will support Apple FairPlay and Windows Media DRM audio playback. Those features are already enabled in the latest nightly build and everyone is encouraged to give those builds a spin. If you’re on Windows you’ll need to have a new-ish version of Windows Media Player (probably 9 or newer) for protected WMA playback and QuickTime for Windows (probably 7 or newer) for FairPlay to work. On OS X you’ll only get FairPlay playback, sorry.

How does this work? We don’t hack out the encryption keys or anything illegal. Songbird supports multiple playback cores so we simply use Apple’s and Microsoft’s own playback engines to do the decoding for us. We use VLC for playback of most file types, but now whenever you play a protected WMA or M4P file we swap in the Windows Media Player or QuickTime core. Sounds easy, right?

Well, no. Not really. The world of DRM is a little (cough) unfriendly, so I figured that I should share some of the war stories and a few tricks for anyone interested in making DRM playback work in their own apps.

It seems both Apple and Microsoft are a little paranoid when it comes to debuggers. I fault Apple a little more than Microsoft in this case for reasons I’ll hit in a second. But be forewarned: using DRM software under a debugger may not work correctly (or at all), and documentation may be totally misleading. What happens? Well…

Applications that use QuickTime APIs on OS X will appear to crash the *instant* a FairPlay track is loaded if the app has a debugger attached. Seriously. The entire app dies and prints “Program exited with code 055″ to the console. What, you don’t know what code 055 is? No one else seemed to, either, except for Google. I was led to an excellent blog post that helped me unravel this mystery. In a nutshell QuickTime aborts the app if it sees an attached debugger and prints that cryptic error message.

For an honest developer (me) trying to use Apple’s public API this is unacceptable. Killing the entire app is entirely unnecessary. Why not just make the load function fail? The QuickTime docs don’t mention this limitation as far as I have been able to find, and that is equally ridiculous. Try searching developer.apple.com for “quicktime 055″ and see how many hits you come up with. I’d even be happier if it printed a simple “Not allowed with an attached debugger” message. As it is I spent quite a bit of time examining my code for changes that could have caused a “crash” before admitting defeat and searching Google.

Fortunately there’s a really simple way around that mess. As detailed in the blog post above, the abort is triggered from the ptrace() function, so using gdb you can do an early return and keep your app alive. I added a gdb script to my machine that automatically skips ptrace() and I haven’t looked back. Except with bitterness.

Now, before I move on to Microsoft I should point out that once the debugging issue was solved I have been rather pleased with the way QuickTime works with protected content. It even works on Windows. The APIs are a little, uh, tough to get used to if you haven’t done much Carbon programming, but with enough time and patience I got an acceptable result (and I learned enough to know that I made some mistakes - I can’t wait to fix some of the code for 0.3).

Microsoft is just as paranoid about debuggers and DRM but they win the “developer friendly” award by a hair. Accessing protected WMA files with Windows Media Player seems just like opening any other file. Your app continues to run (amazing, no hard abort!) except that the file refuses to play under a debugger.

The play() function succeeds as it does for every other file, and let me tell you, it’s really frustrating to receive no error code when you know that something has obviously failed. I ended up adding a bunch of error logging code that examines the IWMPErrorItem associated with a media item and found that Windows Media Player was actually returning an error sometime after my play() call supposedly succeeded. This leads me to believe that play() does nothing more than add the internal play command to a queue somewhere (but good luck finding that in the documentation).

The error code returned was 0xC00D2767, and after a little searching I found that code was defined as NS_E_DRM_DEBUGGING_NOT_ALLOWED: “Running this process under a debugger while using DRM content is not allowed”. Of course I wasted several hours trying to figure out why play() was failing yet claiming success, so I was still royally upset when I realized I had been bitten by the same kind of “bug” that I had fought with QuickTime. But at least Microsoft was nice enough not to kill my app and to actually return an informative error code (albeit in a way that was difficult for me to figure out).

A week ago I had never used the Windows Media Player APIs, and I’m brand new to the QuickTime APIs as well. I’m sure a lot of my frustrations were just the normal headaches associated with learning new APIs. I’m also willing to bet that a bunch of the “bugs” I encountered were caused by me using those APIs incorrectly. I’m used to debugging XULRunner, and whenever I receive an error code I’m unfamiliar with or something fails for no reason I can go look at the code to figure out what’s going on. In contrast QuickTime and Windows Media Player are black boxes, and without good documentation it’s really tough to figure out what’s going on… Add DRM into the mix and the black box turns into a black hole.

Both Apple and Microsoft are trying to protect their DRM schemes (which isn’t a bad idea), but in doing so they’ve made it much more difficult to use their products. Maybe I would feel less bitter if they’d simply stamped a big red “WARNING” banner on their documentation.