Peterism

Note:  I don’t have time to complete this posting right now, so it’s in a draft format.  I just wanted to briefly document my findings before I forget.  Back to studying for the Patent Bar…

I finally pony up the Benjamins and got myself an Android handset, wait for it – the Sprint HTC EVO 4G!

You may not share my enthusiasm, but finally ditching my HTC Mogul (running WinMo 6.1) and moving into an even more open platform opens up a lot of possibilities for me.  I’ve always been more comfortable developing on the *nix realm, and although I don’t have anything against the iPhone, Apple’s tight control on the iPhone OS just doesn’t sound that appealing to me.  At this point in the mobile platform ecosystem, iPhone enjoys a  almost 4-to-1 margin in the number of developers probably due to its two year head start in reaching the mainstream market, but the fact that Google opens up the entire Android platform, allowing me to develop apps that interface the hardware in a low-level way is much more appealing.  I hope for a day when the mobile platform mimics the general purpose computers that makes it possible to run almost any OS on the same hardware.

A bunch of people have been having problem building a true phone recorder on the Android.   Almost all smartphones these days come with an application processor (AP) and a baseband processor (BP).  The BP is responsible for handling the radio, and voice encoding -decoding, among other related tasks.  While the AP is used to run the OS and applications.  The fact that despite having an API that supports recording voice call (both uplink and downlink), none have been able to successfully implement the feature suggests to me that there’s more than meet the eye.  Upon further digging through the Android platform source and documentation, I found an interesting project within the platform that seems to be responsible for implementing what I want…, the Radio Interface Layer (RIL).

More to come…

I have been USB-tethering with my Sprint HTC Mogul for more than two years, connecting my Ubuntu 8.04~10.04 and Win XP~7 laptops/netbook to Sprint’s usually-speedy-enough 3G data network. While my Mogul still works fine as a phone, email client, light browsing, an GPS navigation with Tomtom 7 and Google Map, I am really getting tired of Windows Mobile 6.1.

I am a fan of building custom Linux kernels for the x84 architecture and having root access to an OS, so the ability to do (close to) the same on a ultra-portable embedded device with an ARM architecture with an Android OS appeals to me.

The hardware I want is something like the HTC Evo (4G) or the HTC Desire/Incredible. While the Android 2.1 that comes with them pretty much does what I need, and I think I can always tinker around to get USB or Wifi tethering, the rumor that Android 2.2 will come with that ability built-in gets me fired up.  Sprint says they’ll be charging an additional $29.99/month for Wifi hotspot on the Evo, so it remains to be seen if a carrier will disable the new built-in Wifi hotspot capability so they can charge more.

If history is an indication of what’s to come, I may have a reason to be optimistic.

Back in October 2007 when I got my Mogul, rumors were that there was a GPS module built-in, but Sprint had disabled it in the ROM.  A few months later, Sprint released a new ROM with that GPS module enabled, even though they continue to provide their proprietary Sprint Navigation at a monthly fee.  I hope they somehow decide to allow the native Wifi hotspot, but I’m not holding my breath for it.

So I’ve been wanting to get my hands dirty at cooking up an Android app, and have had dreamed up a few ideas. Some of these ideas have since been implemented by others (barcode scanner with camera that searches for products and prices online, music “recognizer” like Shazam, etc). The latest idea that I have is a mobile app that records live phone conversation on demand.

Quick searches for existing solutions suggest that there are no apps of this kind for the Andoird and the iPhone, but a few good candidates may be available for the Symbian as well as for Windows Mobile.  I’m not certain about the WebOS that newer Palm devices run on.
The idea seems simple enough, but the actual implementation seems to have been curbed by limitations of the baseband processor in most smartphones.  From what I have gathered, most smartphones incorporates two major processors.  One of them is the “general purpose” processor, or that application processor that runs the OS and applications.  The other is a “special purpose” DSP  or sometimes referred to as the baseband processor that handles real-time voice encoding and decoding.   While it’s fairly straight-forward to record and encode local voice using the application processor, capturing the output of the baseband processor, or the remote voice, seems to have caused issues with most developers.

In my quest to write a conversation recorder app for the Android, I came across this class:
[java]MediaRecorder.AudioSource[/java]
One of the values available is:
[java]public static final int VOICE_CALL[/java]
Voice call uplink + downlink audio source
Constant Value: 4 (0×00000004)

This is available since API Level 4, which corresponds to Android 1.6.  It then appears deceptively simple to just set
[java]MediaRecorder.AudioSource = VOICE_CALL;[/java]
to record both the uplink (local) and downlink (remote) audio feeds.  I don’t actually have an Android phone to test on, but if you do, and have the means to load your code onto your Android phone, please let me know if you get 2-way voice recording going.  As I’ve said, it may depend on the capabilities of the baseband processor you have.

I’m eyeing on the HTC Passion/Google Nexus One, which is rumored to be based on Qualcomm’s Snapdragon QSD8x50.  The QSD8650 is especially interesting, with some reports having said that it may be clocked at 1.3GHz, with the capabilities to run on both the CDMA and GSM families of 3G data networks, making it a powerful world phone.  Detailed specs are especially hard to find, but I’m hoping the baseband processor inQSD8x50 will expose the downlink audio to the application processor, by perhaps providing some sort of DMA to the cache that the baseband processor uses.

I’ll report my findings as more details are available in the coming days, I hope, as the Passion/Nexus One is supposed to be coming out in as early as January 2010!