While looking over TwitterGram web service doc, I read:

The ideal client for this service, it seems, is Flash, because it can do the MP3 recording and has XML-RPC support.

I am not sure if Dave knows this but Adobe crippled audio recording in Flash so that bits from microphone are always sent directly to server-side <strike>*without* compression</strike> using a proprietary codec (NellyMoser). This means server has to capture and encode the bits into MP3, not the client. Yes, high server load should be expected. And since bits are sent in RTMP stream, your backend choice is limited. Adobe is expensive. <a href="//osflash.org/red5" target="_blank">Red5</a> is java-based. I&apos;ve heard good things about <a href="//www.amfphp.org/" target="_blank">AMFPHP</a> although I am not sure how much work is needed to use it to record audio.
If I had the ears of those in charge of Flash roadmap at Adobe, I would whisper:
<ol><li>Enable client-side audio and video recording (MP3 + <a href="//www.speex.org/" target="_blank">Speex</a> or better to start with) </li><li>Add UDP-based notification listener support (<a href="//en.wikipedia.org/wiki/STUN" target="_blank">STUN</a> to punch out)</li></ol>

Sure, there will be issues but these two features will kick many doors down, enabling new web applications practical. What separates toys from tools is the difference between possible and practical.
Update: I thought the audio was a simple variation of WAV but apparently Adobe is using NellyMoser, a proprietary mono-channel codec optimized for real-time speech. I am not sure if it's better than Speex (I doubt it) but that doesn't matter until the format is documented and free license offered to Flash developers. Fugger.