Streaming to Mobile Devices
Apr 1, 2010 12:00 PM
Trends in Technology, April 2010
It seems like only yesterday (it was actually more than a decade ago) that we plopped a 300-user license WME server at our local ISP and streamed audio to our more tech-savvy listeners who had some amount of trouble picking up the station over the air. There was no money to be made in it at the time; we looked at it as more of a listener service. Plus, it was a relatively new technology that we just thought was pretty cool.
Fast-forward to 2010: Streaming audio is now essentially a requirement for any radio station. The number of users receiving radio station audio streams is rapidly increasing. Bridge Ratings Service has recently concluded (based on its research) that more than 60 million people in the United States listen to some form of Internet radio during the course of a typical week. Perhaps more importantly, Bridge is predicting that number will rise to 77 million by the beginning of 2015. That’s a 28 percent gain in 4 years — a prediction that we all have to take note of. Add to that, Gartner Research has recently predicted that the number of mobile Internet devices will exceed that of desktop devices as early as 2013.
If your station hasn’t already done so, it’s time to look into providing streaming for these mobile devices. Your competition is. The Pandoras of the world already are.
Choices, choices
When an end-user goes out to buy a phone he has many choices not only in the device itself but also in the network that it resides on. Probably the best known devices are the iPhone, the Blackberry series, and the Droid. (There are others of course). I’ll refer to these simply as platforms.
Perhaps the biggest difference between “broadcasting” to mobile platforms, and over-the air transmission is that there are multiple ways to stream and they are specific to the platform type and network. For example:
iPhonehttpMP4 (AAC)64 or 40kp/s BlackberryhttpMP4 (AAC)64 or 40kp/s Motorola DroidrtspMP4 (AAC)32kp/s Flash encoderrtmpMP4 (AAC)64 or 32kb/s
This table is obviously not complete; there are other types of phones, but this gives you an idea of what’s available.
We OTA broadcasters have for years delivered a specific format (for FM, 15kHz audio bandwidth, +/-75kHz deviation, 75�s emphasis), and receiver manufacturers made radios compatible with the standards. The game has changed now somewhat � we need to play by their rules. The bottom line is that you will have at least one and perhaps more computers generating streams targeted for the various available platforms.
— continued on page 2
Streaming to Mobile Devices
Apr 1, 2010 12:00 PM
Trends in Technology, April 2010
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
Streaming to Mobile Devices
Apr 1, 2010 12:00 PM
Trends in Technology, April 2010
Putting it all together, end to end
Let’s take a look now at how a connection is made end-to-end when an end-user clicks on your application.
For starters, part of what the application developer does is to code the unique URL you want to use for a particular stream. Obviously a different URL can be used on the basis of the platform type.
After this URL is resolved, a redirect server is reached. In addition to redirecting you to the yet another URL, this server likely takes note of the fact that you requested the service. (You’ve just become a statistic.) This second URL points you to the CDN.
At the CDN, your request reaches a DNS that does a few things:
- Reads the source of IP address of the requester
- Does a lookup of the owner of that IP address
- From that owner information, a reckoning is made of the location of the requester
- The DNS then decides which of its POPs is the best place to serve your content based on: The closest physical proximity; network congestion encountered reaching that POP; server usage at that POP; and load sharing.
Once the CDN’s DNS comes up with an answer, it resolves the requested URL into an IP address for the user to attach to. The last mile connection is now made — via unicast. In the case of mobile devices, the physical layer is done via two radio links: one from the cell site to you, and of course the other from you back to the cell site.The number of of smart phone users keeps increasing, and there’s no end in sight. I for one don’t believe streaming will ever supplant broadcast radio, but it is abundantly clear that streaming is growing in importance in our business. If you haven’t already availed yourself to the new crop of Internet listeners, now is really the time. It’s still early in the game, and definitely not too late to get in.Resources - AirKast
airkast.com - Akamai
www.akamai.com - AudioTX
www.audiotx.com - CDNetworks
www.us.cdnetworks.com - Limelight
www.limelightnetworks.com - Orban
www.orban.com
Irwin is transmission systems supervisor for Clear Channel NYC and chief engineer of WKTU, New York. Contact him at[email protected].
