Android Ramblings, Craigslist Adventures, Technical Nonsense

I've put an updated version of Lame4Android out on the Android Market today, and while I'm glad to say it now supports decoding WAV->MP3, it does still have one small glitch, where feeding in files created using Lame4Android will not encode properly. I have a feeling that this is due to the first few bytes of the file not being skipped correctly, which causes the encoder to crap out immediately. I will have a fix for this soon. 

Now, on to what I wanted to talk about. Any programmer over the span of their career will have written an API of some shape or form. It may not be good, or widely used, but they'll have done it. This is one of those parts of programming you wish they taught everyone else in school, along with variable naming and spacing, in that you'll wish everyone wrote their APIs like you would. It's also one of those things where everyone can tell when there is a good API, but cannot necessarily write one themselves. 

I've had plenty of experience (attempting) to write APIs, but the first time I truly had to worry about what I was writing was when I worked at Deluxe. At the time I was given the task of re-writing the framework on which all of the Universal Blu-Ray releases were written on, since the previous version was getting a bit long in the tooth, and did not support some of the newer base framework functionality. Additionally it was full of strange quirks and unnecessary wrapper functions. Now here I think is the crux of writing a good API: exposing the right amount of magic to the client program. What I mean by this is that the amount of magic the API does behind the scenes to provide the functionality available underneath must not be too little, nor too much. Too little magic in the API and you're left with a nothing more than a thin wrapper around the underlying functionality. An example of this would have been the Universal Blu-Ray framework I was talking about earlier. In quite a few places the old framework would provide wrapper functions to switch audio tracks (think switching from French audio to German) that was nothing more than a wrapper around the underlying base framework's switch audio track functions. On the other hand, too much magic in the API leaves you with a very inflexible set of exposed functionality. An example I'm thinking of would be the Android MediaRecord API. While the designers expose pretty much all the functionality a developer would need to record audio, it just isn't very configurable. You can only record in a certain format, and then only directly to a file, not to a buffer, or to the speaker, or anything else. Nor can you (not until Gingerbread at least) apply effects to the recorded stream. In order to do any of the above, you as a developer must use AudioRecord, which only outputs to a buffer that the developer must manipulate. Too much work is done by the underlying layers, all of it magical to the client programs.

Now to get back to the point of everything though. Today I'd like to say the liblame API is finished (or as finished as a hobby project ever gets), and I'd like to say I did a good job in exposing enough magic to anyone who would like to use it. Please let me know if you do, I'd love to hear from you.

I've recently been bitten (again) by Samsung Galaxy S AudioRecord bugs, and after having to ignore it to focus on classwork for the past few weeks, it's time to get back into it. The last MicDroid update featured improved error handling due to proper (sort of) use of exceptions instead of an Android Handler to route all exceptions to error handling code. Unfortunately this broke Galaxy S support due to what I believe is described in these posts. It appears the Galaxy S phone just locks up the AudioRecord if you try AudioRecord.startRecording() while it is initialized improperly. This behavior certainly seems consistent with the (mass of) bug reports I've been getting from users. I think I'm going to have to try some of the dirty hacks mentioned above to fix it.

Another project which appears not to have had too many issues with the Galaxy S series is the rather famous Sipdroid. They also have AudioRecord code which supposedly works on the Galaxy S series. They use an interesting method of delaying until the next frame is read before reading from AudioRecord again. I'm fully intending to try this method out also, since if it works, it means I can potentially simplify a lot of the complex recording code current around. Also, it could potentially mean fixing the horrible buffer size hacks I'm using right now and finally allow the Galaxy S series to take advantage of live recording.

Should I get it to actually work, I definitely plan on releasing details.

Finally, the last, best hope for the Galaxy S series is the upcoming release of an official 2.2 ROM. There have been rumors that the 2.2 ROM fixes a lot of the audio bugs that plague the 2.1 Galaxy S ROM, and should an update that fixes these fully roll out, all of these horrible Galaxy S problems should be solved. Obviously this is the best solution for everyone :)

Something else I've been throwing around in my head has been the fact that the Galaxy S has a relatively slow internal SD card. I'm wondering if this has any effect on recording, especially if AudioRecord.read() reads audio at a rate faster than the phone can write. 

It's problems like these that really have me looking forward to Gingerbread, as it's OpenSL and effects pipeline support can potentially go a LONG way towards resolving basic audio functionality issues like these. Now if only we could get Google to release the source code and Samsung to follow standards and release fully baked hardware...

Google announced Gingerbread today and the list of new shiny things to play with is quite long. It includes things like a complete native API for activities/OpenGL ES/OpenSL ES/sensors, audio effect API, and NFC. Of particular interest to me is the OpenSL ES, audio effects, and AAC encoding APIs. It's very obvious to see that these platform changes are meant to push Android gaming in a serious way. Google is hoping game developers will sign on, meaning we might see quite a few more corporate-produced games. All of this will mean a lot of interesting things for the future, especially for MicDroid. Unfortunately all of these fancy new toys are available only under 2.3, meaning we will all need to start pushing for updates from our phone providers. :) 

Finally, I'd like to take a minute to talk about MicDroid and updates. Especially the fact there haven't been too many in recent weeks. The most obvious reason for this is that I'm back in school, and classes are taking up a significant portion of my time. I'm hoping (again) to get more free time in the coming 3 week holiday break to put some fixes out for Galaxy S (which I cannot test easily), and (finally) finish up LAME MP3 support and background music import. Additionally, I'd like to take a moment to apologize to Galaxy S users for the latest update. I'm not certain where the failure is coming from, but my suspicion is the audio hardware initialization and wave writing code. I can't really imagine going out to pick up a Galaxy S phone, but if any kind soul out there would like to lend some Galaxy S testing time, it would be much appreciated. Finally, I'm also going to be looking at integrating new 2.3 features, as well as hoping that Google drops the 2.3 source code soon :)

Happy holidays!