Audio and Video Streaming for the Masses
Linux has garnered much attention in the mainstream press recently. Such publicity has been both a boon to Linux enthusiasts and advocates, and a source of curiosity to those who may just be learning of this marvelous operating system. I am very encouraged to see Linux growing in popularity. It's always pleasing, however, to see this popular media attention complemented by concrete examples of Linux in everyday use. As one of those fortunate individuals who gets paid for his passion, I would like to provide one such concrete example by sharing details of how we use Linux at Global Media Corporation.
Global Media Corporation (http://www.globalmedia.com/) is a publicly traded company that has built a private network for the transmission of live audio and video over the Internet. For Network Associates who want to stream their content and/or offer merchandise through electronic commerce, we provide a ready-made infrastructure based on Linux.
I work on the Network Engineering team (see Figure 1) where Linux is the heart and soul of what we do. Credit for this commitment to Linux goes to Marco Belmonte, our Technical Lead. When the Powers That Be were planning the whole project, Marco told them of Linux. He showed them how Linux would provide a reliable, scalable, flexible network and be cost-effective. We haven't looked back.
To broadcast over the Internet, we send a Linux box to the Network Associate. This is most often a radio station, but can be anyone with an audio source. The box is connected to our Network Operations Centre (NOC) and to an Internet access point over our private frame-relay lines. From the NOC, we can monitor, control, configure and update all the remote stations.
The boxes consist of Intel Celeron-400 chips on Abit socket 370 ZM6 motherboards with 64MB of RAM. The motherboards are equipped with Winbond monitors to ensure we can detect intrusion and track temperatures, voltages and fan speeds. This is important so that we can ward off problems that might cause the box to crash—no broadcaster likes dead air. The audio feed enters the box through a SoundBlaster 128 card. The encoded signal leaves the box through a Sangoma S508/FT1 WAN card. A 14.4 Hayes-compatible modem allows us to carry out emergency maintenance should something happen to the frame-relay connection.
This is a good moment to offer special recognition to Sangoma Technologies. As mentioned, Sangoma is the maker of the WAN cards (see Figure 2) we use to connect our boxes to the frame-relay network. Sangoma is also one of the few hardware manufacturers that has recognized and supported Linux from its earliest days. In the context of Global Media, this recognition is particularly appropriate, as they spent many hours adapting their software so we could configure their cards from a script rather than interactively.
Returning to our setup, the encoding boxes run a customized distribution of Linux. Since the machines would never have been used as workstations and only a few services were needed, the boxes were stripped down to core libraries and utilities. Added to this slimmed-down distribution were special configuration and monitoring scripts and the software for digitizing the audio signal.
To avoid the work of installing our distribution on every machine, the boxes are built from cloned disks. The cloning of disks and assembly of boxes is contracted out. The contractor ships a box to a new site after entering a unique identifier we specified. This identifier serves to configure the machine once it arrives at its destination.
Configuration is done over the wire by automated scripts. We chose this method for a number of reasons. First, as the boxes are shipped directly from the point of assembly, we have no opportunity to do the work ourselves. Second, security concerns dictated that we not provide elements of the configuration information to third parties. Next, we wanted the setup and operation of the box to be as simple as possible for our customer: they should only have to plug in the box and turn it on. Few clients, if any, would be comfortable running Linux commands on a text console. In addition, leaving this to the customer would increase the potential for typos and other related errors that would likely cost us many hours on the phone, trying to debug the problem. Finally, configuring machines by hand is drudgery best left to machines.
Automation ensures the boxes are configured and operational, both quickly and securely. Upon receipt of the box, the customer first attaches all the cables, then turns it on. From the boot scripts, a configuration client detects that the box has not yet been configured and contacts a configuration server in our NOC. Using the identifier sent by the remote box, the configuration server queries a PostgreSQL database to acquire all the appropriate information. Once the client has configured itself, it becomes part of our broadcast network. From that moment on, any audio coming into the box is available for listeners on the Net.
I mentioned we use private frame relay to pick up our audio signals. We could have simply used the Internet for this, but chose a private network in order to ensure the quality of the signal as far as possible along the path to the end listener. Using the Internet to gather our signals would have subjected us to congestion and competition for IP bandwidth. We would be forwarding to listeners an already degraded signal. We don't simply want to get listeners to their destination; we want to get them there in style.
RealNetworks—one of Global Media's partners—is our link to the Internet. RealNetworks relays our audio streams to their globally distributed network of servers. When a listener requests one of our URLs, RealNetworks determines the origin of the request and delivers the stream from the closest point. Thus, the portion of the total route that the requested stream has to travel over the Internet before reaching the user's player is reduced to a minimum. For the rest of the route, the stream travels over dedicated high-speed lines.
RealNetworks also provides us with the software that encodes the analog audio source (it runs on Linux) and the Global Media Player. RealPlayer and RealPlayer G2 can be used to listen to our streams, but the Global Media Player links the stream to the Network Associate's editorial content and storefront.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
58 min 50 sec ago
- Reply to comment | Linux Journal
4 hours 58 min ago
- Yeah, user namespaces are
6 hours 14 min ago
- Cari Uang
9 hours 46 min ago
- user namespaces
12 hours 39 min ago
13 hours 5 min ago
- One advantage with VMs
15 hours 34 min ago
- about info
16 hours 7 min ago
16 hours 8 min ago
16 hours 9 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?