The challenges of streaming audio to mobile devices and moving vehicles
This month we revisit the topic of streaming audio to mobile devices – with an emphasis on vehicles. What does it take to stream audio into a car “radio?”
Unlike over-the-air transmission (with a single standard of 75kHz deviation, and 75µs pre-emphasis), there are multiple ways to stream to mobile devices, and the data rate depends on the device’s network. Table 1 provides some insight.
Table 1. Various data rates and protocols for mobile devices.
The bottom line is that you will have at least one and perhaps more computers generating streams targeted for the different platforms out there. More on that a little later.
With respect to a particular platform, you will work with an application developer in determining the protocol (such as HTTP or 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, the app developer will build the app around those basic parameters. And speaking of applications developers, very few broadcasting companies have the wherewithal to have their own in-house; that’s where a company such as Airkast comes in to the picture. Its product called TuneKast is specifically for broadcasters; think of it as a turnkey solution that encompasses necessary applications, trafficked ad-insertion, title and artist displays, and finally distribution via CDN.
StreamOn is another provider of streaming services. It provides a small appliance (running on Unix) to the radio station that encodes the audio in AAC+, Ogg Vorbis and in some cases MP3. This appliance then sends the stream outbound for subsequent distribution to end users. If the radio station provides the appropriate metadata, then the StreamOn player will show title and artist information. StreamOn can also build custom iPhone apps, or integrate with existing third-party apps. Perhaps most importantly, StreamOn offers Ad Tools, which is a way to generate revenue from the streaming content.
Liquid Compass also offers custom apps for mobile phones in addition to their support of desktop players. Some of the features it offers: now-playing (of course); social media integration; on-demand access to local weather and news; and finally a favorites repository for the end user, along with music history. Naturally, it offers a means by which ad-insertion can be done as well through a partnership with AdsWizz.
The challenges of streaming audio to mobile devices and moving vehicles
Inserting ads
Ad-insertion technology is the subject of its own article, and we covered it in “Streaming Audio Ad Insertion” in the September 2010 issue of Radio magazine. However you decide to accomplish that, there will be a point in your content delivery chain that you’ll need to get audio into a CPU for generation of said streams. Clearly you’ll need a soundcard, and likely some audio processing optimized for lossy codecs. Most likely you’ll want to send along metadata as well – at the very least “now playing” information.
One possible choice for those functions is the Orban Opticodec. The Opticodec can be used to generate streams using HTTP, RTP 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 PC1101, which not only plays the role of sound card, but audio processor (among other things). You can enter your metadata into the Opticodec by means of a text file, serial connection or Ethernet.
Another option is the Telos ProStream. This is a 1RU device that takes audio in (via Livewire, analog or optionally AES) and generates an MP3 stream, an MPEG-AAC stream or a Wowza stream. On-board audio processing was developed by Omnia. The device has several outputs: one for processed, un-encoded audio, and one with processed, coded audio. It has two Ethernet connections: One is meant for local network connections (including metadata) and the other for the WAN/streaming out. The unit is controlled via a Web browser, though it has front-panel controls in addition.
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 and MP4/AAC; and it’s Winamp/Shoutcast/Icecast capable. Metadata access is via RS-232 or an IP text-based interface. According to AudioTX, you can locate the Webstream at your ISP and stream up to 25,000 users.
If you were to use your own streaming encoder barefoot you would certainly need some sort of outboard audio processing; in that case you might want to consider the Vorsis VP8+ from Wheatstone. It has two processing modes optimized for lossy-codecs used in streaming: MP3/AAC greater-than 48kb/s and MP3/AAC less-than 48kb/s. It’s a single rack-unit, with analog and AES inputs, and it’s configured via the front-panel or via a computer, using a windows-based GUI.
The challenges of streaming audio to mobile devices and moving vehicles
Accessibility
Once the stream is generated it’s clearly very important to make it easily accessible to all the end-users. You could plant a server yourself at an ISP, and make use of the ISP’s high-speed connection and peering with other ISPs, but that isn’t typically how it’s done. In order to provide the best user-experience, you need to minimize the number of hops the stream must transit on its way to the user. Let me explain why.
The public Internet is basically made up of connections between ISPs (and other large users). These connections are made between larger routers – or peers – at many, many locations. In certain circumstances there may be multiple routes between organizations and ISPs; some connections may be done via load-sharing, meaning that packet streams are broken up, and literally routed over more than one route between points A and Z.
Streaming such as we are talking about uses UDP – the best effort methodology in IP communications. Packet sequences are numbered, so that at the far end they can be re-assembled in the right order. A couple things can happen along the way for these packets as they transit the Internet. For one thing, it takes a finite amount of time to make the trip, and transiting more hops extends the time. Secondly, in the event that the packets are sent along different routes (load sharing) they may arrive at the far end way out of order. Of course the decoder at the far end uses a buffer stage to give itself a little time to re-organize packets that come in out of order, but it cannot make up for packets that are simply lost and never make it. More hops increase the chances of lost packets; too many lost packets means a noticeable drop-out in the audio. No user likes that of course.
The challenges of streaming audio to mobile devices and moving vehicles
One way to overcome these issues is to make use of a content delivery network (CDN). CDNs make use of private connections (often spread out over the entire globe) so that they can provide a much greater level of control in how the packets get from point A to a point very near the end-user. This to a very great extent mitigates the packet loss and/or delay issues just described. Plus, it’s a very practical way to serve thousands upon thousands of end users, something that is hardly practical for radio station to do (via IP anyway). A few of the more well known CDNs are Akamai, Limelight, Level 3 and CDNetworks.
Now let’s look at streaming to mobile devices in greater detail. We have a stream of packets that originate at your studio location, and find themselves peered from a CDN in to the IP network of one of the large cell phone providers, such as AT&T, Verizon or Sprint. They’re just about ready to make that last-mile journey to a listener’s smartphone. Verizon and Sprint use EVDO, and AT&T uses UMTS. In either case, the backend of the network is built to handle IP traffic. The way this is done has changed as well; in the days of 2G and even for 3G, many base stations were connected back to the base station controllers via T1s. Today that isn’t really fast enough. The cell companies are building new IP-based backhauls to accommodate more and more users with more and more smartphones.
Even though the terminology is slightly different from system to system, they each use three common devices. First, and what’s most familiar to us, is the base station. This is the last mile link done via radio. The base stations find themselves under a radio network controller, which performs several different functions, not least of which is instructing the base stations to hand-off the phone from one cell to the next as required. (For LTE, we have two devices: the serving gateway, and the mobility management entity.) Finally the data itself is connected to and from the IP network by way of a gateway. Routing of that data all the way back to the peering connection is what gets us back to the CDN (or perhaps the public Internet).
When the data itself makes its way to your smartphone, you could of course listen to the tiny built-in speaker, ear-buds or a headset. To make the connection to your car’s audio system you could simply make a short cable connection, by way of a mini-stereo jack on the radio itself, or an adaptor of some sort (such as an FM modulator). But let’s go with the most up-to-date way: Bluetooth. Many vehicle audio systems now come with Bluetooth as a means of connection to other devices. Bluetooth isn’t really new (it was developed back in the mid-1990s) but it clearly has a lot of marketing presence now.
Bluetooth is simply a technology used to make a small ad-hoc network (known more regularly as a piconet) that can consist of up to eight devices. The devices communicate via frequency-hopping spread-spectrum in the 2.4GHz ISM band. One of the devices operates as the master, and the others are slaves. The master synchronizes the system, addressing each slave in turn, in a round-robin fashion. With a transmit power of 0dBm, the range is expected to be less than 15′; data throughput is on the order of 2Mb/s.
To complete the connection, it’s necessary that the car audio system and smartphone have A2DP (Advanced Audio Distribution Profile) capability. A2DP is a Bluetooth profile that allows for streaming stereo audio between devices that are members of the piconet. Makers of car audio systems that support A2DP include the well-known brands Pioneer, JVC, Sony, Alpine and several others.
The challenges of streaming audio to mobile devices and moving vehicles
AM/FM vs. streaming audio to a vehicle
So now that we see what is involved in getting streaming audio into a vehicle, here’s a short comparison of the steps involved with respect to each technology.
For AM or FM:
- Generation of program audio
- Relaying program audio to transmitter site
- RF signal generated, radiated
- RF signal received by car stereo, demodulated, played out to user
For streaming audio:
- Generation of program audio
- Generation of stream (or streams) by computer-hosted codec
- Relaying of stream to CDN by means of IP network
- CDN peering to major wireless provider
- IP connection from peering location to base station, as directed by base station controller
- RF signal generated, radiated
- RF signal received, data decoded
- Decoded data used by A2DP over Bluetooth connection to car stereo
- Data taken from A2DP stream, decoded, played out to user
While it’s clear that the technology to stream audio to a moving vehicle exists, it seems pretty clear that there is much more to it than there is in getting plain old radio into a vehicle. As the technology moves forward, and more applications become available for vehicles, more data throughput will become necessary, and from plain old economics (the law of supply and demand) it seems obvious the cost of streaming will go from zero to some (at least) modest amount. This will become a headwind for the increasing acceptance of streaming audio in-vehicle; some people will pay, and not care; others will be more frugal. It will also be quite some time before enough new vehicles with Internet access and/or Bluetooth capability make their way to end users for this transmission means to have a substantial impact; car sales are certainly not what they were prior to the recession. Older vehicles with old-fashioned radios are going to be on the road longer due to the economic situation.
With all that said, I still believe it is vitally important to make use of and optimize every means at our disposal so that listeners can get our content in the way they prefer, whether that is via terrestrial radio or via streaming over the Internet.
Irwin is transmission systems supervisor for Clear Channel NYC and chief engineer of WKTU, New York. Contact him at [email protected].
