There's an app for that
We've all heard that catchy little ditty now. Well, there is going to have to be an app for your station if you want to get in the game. Unless your company has the wherewithal to have its own application developers, then look to outside contractors to write the apps for you. (There is at least one company out there that will turn-key this for you — AirKast.) Once that gets done, and the app receives approval from the particular app store, your listeners can then be directed to the app store to download it.
With respect to a particular platform, you will work with an application developer in determining the protocol (such as http, rtsp or rtmp if using Adobe Flash). You will chose the data rate likely in conjunction with the network provider and network type (i.e., UMTS or CDMA2000 [EV-DO]). You will chose the lossy codec (such as AAC) based on what you want the stream to sound like to the end user. Once you come up with those specifications, you will then build your streaming encoder around them.
There are several different ways to accomplish this. The most obvious way is to assign the task to (yet another) CPU that lives at the radio station. This machine will have a piece of software that performs the encoding. One possible choice here is the Opticodec from Orban. The Opticodec can be used to generate streams using http or rtsp, compatible with Winamp/Shoutcast/Icecast, using MP4/AAC or HE-AAC for the lossy codec. Multiple streams can be generated simultaneously on one CPU, and the number of (unicast) streams depends upon the CPU power. I should note also that the Opticodec comes coupled with the Orban PC1100, which not only plays the role of sound card, but audio processor as well (among other things). You can enter metadata into the Opticodec by means of a text file, serial connection or Ethernet.
AudioTX offers Webstream, a 1RU encoder that can play the role of stream generator. This device can encode up to six streams with different format/bit rate combinations. Two of the lossy codecs available are HE-AAC as well as MP4/AAC; and it's Winamp/Shoutcast/Icecast capable. Metadata access is via RS-232 or an IP text-based interface.
And speaking of metadata: This is information such as "now playing" that ultimately gets parsed out by the application on the user end. That way listeners can have the artist and title info, along with whatever else you happen to come up with when working with the app developer. There again, you may work with an outside service that gives you database access to album cover art -- which you can also display along with the title information.
Streaming for everyone
Once the stream is generated, it is sent via IP unicast to the organization that makes it easily accessible for users over the Internet. You could plant your own server at an ISP and make use of the ISP's high-speed connection and peering with other ISPs, but that really isn't the way to go. It's important for the end-user to be attached to the best streaming source for his particular location so that the number of hops between the actual stream source (a replica of what you sent) and the end user is minimized. Let me explain.
When a connection is made from a mobile device and a source (a bank website for example), the amount of time that the communication takes isn't really important (unless of course it is monumentally slow). That communication is based on TCP, which is the connection-oriented, reliable transport method in IP. The source (the bank) is going to know from communications with the end user (you) that all the packets were received, and that they were all error-free. For this reason, it doesn't really matter how many "hops" (or routers) were transited over the Internet so that those packets could reach you and in return packets generated on your end could reach the bank. With more routers in the way, the likelihood of dropped packets increases, but since the transport is TCP, those errors are corrected.
With streaming audio, though, that is not the case. Most streaming audio uses UDP, which is the best-effort transport methodology for IP. Packets are given sequence numbers so that, should they arrive at the far end (the mobile device) out of order, they can be put back in the right order. Packets also don't necessarily arrive in a continuous stream; they may come in bursts. Those issues are dealt with by the device by buffering. If packets don't arrive soon enough, the buffer space will empty, leading to drop-outs in the audio. The more hops between the device and the source, the more likely that is to happen. Of course if packets are missing altogether, they can't be replaced. This would also lead to drop-outs in the audio.
The best way around these issues in general is to use a content delivery network. A CDN is basically a large network of servers that physically sit at important points of presence (POPs) where they can make effective peering connections with large last mile networks such as ATT, Verizon and Sprint. The servers on the CDNs own internal network are connected together on a private network with very high data rates (read Gb/s) and as such are not affected by the vagaries of the Internet in general. By constructing the network in this fashion, thousands of users can be served with very few hops in the way -- this ultimately improving the system's performance and enhancing the user's experience. A few of the more well-known CDNs are Akamai, Limelight, and CDNetworks.
-- continued on page 3