This is a very brief and not overly detailed explanation of the inner workings of TweetRadio, a little experiment in mixing media I put together for a  gem of a [mostly] monthly web publication, The New York Moon.

Core technologies:

• PHP5 for main functionality
• MySQL for persistence
• Festival TTS and LAME for rendering text and compressing sound
• A multithreaded Ruby script to glue all the components together and keep them in sync, using the Looper gem
• Slicehost and Amazon S3 for scalable, reasonable hosting
• Most importantly, the Twitter API

There are three core components, all being called and monitored by the Ruby script, which I call the Shuffler. (PHP lacks thread support, and also would have been much more verbose to write the monitor in).

Collector

• The collector uses the Zend_Service_Twitter class to grab tweets from the public timeline as well as @replies tthe @tweet_radio bot.
• These tweets are scrubbed of URLs and other non-naturally speakable elements
• Each tweet is run through the Google Translation API’s language detection resource to filter out non-English tweets or those that don’t contain enough “readable” content.
• Common Twitter idioms (@mentions and #hashtags) are translated into radio equivalents. For example, an @mention might become a “shout out,” and a reply to tthe bot might be a caller on the line, etc.
• Scrubbed tweets are saved to the database for later rendering.

Renderer

• The renderer pulls ~2 minutes worth of read text, or about 20-25 tweets, from the database, mixing the public timeline with some “call in” bot-mentions for a radio-like feel.
• The selected tweets are translated into a special-purpose XML format, SABLE, used by text-to-speech engines to mark up text for rendering by a speech engine. Static is also inserted in between tweets using a SABLE reference tag to an external white noise file.
• The SABLE file is run through Festival, an open-source Text-to-Speech (TTS) engine, resulting in a WAV file.
• The WAV file is compressed using LAME, an open source encoder, into a very compact MP3. This MP3 is saved and assigned a unique ID in the approximate sequence of tweets, which is noted in the database.

Deliverer

• The Deliverer determines what the “current” playing audio file is by examining the table of rendered files and their timestamps. The URL to this file is provided tthe Flash client on request from a simple static file containing the URL.
• MP3 files are uploaded shortly before they are used to Amazon S3, for both cheaper bandwith and better scalability.

Questions? Shoot me a tweet: @mhkt.