Tech Design Decisions Behind Gram Vaani’s Radio Platform

This is a post more for the technology minded, but even others should find it interesting to get an inside view of what goes into designing appropriate technological systems in rural contexts that we are addressing. We’ve made many design decisions along the way, based on our prior experiences, foresight into expected problems, and observations made while visiting and learning about community radio stations in India. I will first outline some important technological goals that we want to achieve, then describe details of our platform, and finally show how our platform will be able to meet these goals. There will of course be changes along the way as we gain feedback from our upcoming pilot deployments, but our insight so far has been that careful thought into appropriate design is crucial to increase the chances that technological systems will be able to fit into the social and cultural context in which they are meant to be deployed.

Technological goals

• Low cost: Clearly one of the most important requirements, we figured early on that specialized hardware such as audio switchers and breakout boxes add to the cost of setting up a community radio station. Therefore we decided to do as much stuff in software as possible, so that a single desktop PC could be used as a library store, a broadcasting system, an archiving system, a telephony server, all in one. The challenge of course being that how do we overload so much functionality on to a single box, while still preserving good audio quality? Well, that’s where good software design comes in!

• Robust in challenging climatic conditions: India is a hot country. Temperatures in the summers go up to 48C in most interior areas. Add to that all the dust that blows around, and keeps increasing as deforestation progresses unabated. Whatever hardware we use, it must be able to sustain such harsh climatic conditions because air-conditioning a radio station only costs more money.

• Platform independent: Our system should provide a user interface for both Windows and Linux. Windows because most Indians really prefer Windows since familiarity with Windows helps them get better jobs. License costs are really not a problem because pirated copies of XP are available in abundance. And Linux because it’s much better, and because many non-profits are now waking up to the power of truly free and open-source software, and are pushing the upcoming community radio stations in India to start using Linux.

• Flexible and incrementally deployable: Our system may not always be used in greenfield setups only for new community radio stations. Existing radio stations may want to use our system as well, but would need a migration path to gradually move various functionality one at a time to our system. Therefore, it should be versatile enough to be able to fit in a plug-n-play manner in almost any radio station setup, and be continuously reconfigured to gradually handle more and more tasks.

• Easy installation and configuration: For increased outreach, we want users to be able to simply download our software, buy the recommended hardware, follow the installations instructions, and get ready to go. This means that installation and configuration should be brain dead simple because many of our users may not be tech savvy to follow complicated setup instructions.

• Remote maintenance: Since it will not be feasible for our technicians to travel long distances to remote radio stations to handle any misconfiguration failures or software bugs, we would like to fix things remotely to the maximum extent possible. But this can be quite challenging because most stations may not have Internet connectivity unless we set up some kind of a system for them. It may seem like a chiken and egg problem, but we think we have solutions!

• Low power consuming: Given the erratic power situation in Indian villages (and cities), and the high costs to set up a soundproofed diesel generator, we want to use low power consuming hardware so that it can just run off solar. Unfortunately though, the lower power consuming a computer is, normally lower is its computational capability.

• Platform to build applications: Although this appears as our last goal, it is indeed a very important goal that deserves some explanation. What is a platform and what is an application? As an over-simplified analogy, if you consider the Internet as a platform that provides data connectivity, then email or youtube or amazon are examples of different applications built on this platform by leveraging the connectivity features provided by it. In the same manner, our platform essentially enables radio broadcast, archiving, library categorization and search, and telephone dial-in/dial-out features. But these features can be mixed and matched to build different applications on our platform. A marketplace is an example where people can dial into the radio station, record local classifieds, and the ads can later be played out over radio. Similarly, agricultural consultancy is an application where an expert can dial into the radio station and conduct a live broadcast, or even reply to questions put up by the audience. A poll is another example where people can dial into the radio station or send SMSes to record their responses, which can later be statistically plotted and analyzed. For each of these cases, we want our platform to provide an API that exposes the underlying radio/telephony/library services, and allows these services to be easily composed into complex applications. The reason for doing this is obvious — a generic platform design which can be used to build innovative applications that we may not have even thought about right now.

System design

So, what have we done to be able to meet these goals?

• One-box system: We are currently using one of the m-series Via mini-ITX platforms that run at 533MHz. These are small boxes, something like 7”×2”×8”, which have a power consumption of the order of 20W. We are testing this on a Soekris box as well, which has an even lower power consumption.

Another advantage with our one-box design is that it can either be used as a radio broadcast console in itself, or, as shown in the figure below, it can be plugged into an existing radio broadcast system. Here, the server for audio broadcast/archiving/telephony runs on the box, while the UI runs on the standard Windows or Linux PC used by the radio station. This plug-n-play design makes our system quite flexible to fit in practically any radio station setup, or to even start a radio station from scratch.

Many of the Via and all the Soekris models also come with large heat sinks without a fan. Not having a fan is a great help because fans are really not good in dusty environments. They get dirty quite soon, and if not maintained properly, then the CPU is endangered of over heating and cooking itself.

• Good software design: It is hard to explain this in detail, but we have managed to keep our software with a very low memory footprint. The UI currently runs in 30 MB, and the server side services consume another 20-30 MB. We were able to do this by designing a custom in-memory cache that eliminates multiple copies of the same data object, and also reduces the amount of database accesses. This makes our software very responsive, kind of in an AJAX like manner for web applications.

• Java: We chose to write our UI and much of the server in Java, which makes our system platform independent. The UI can run in both Windows as well as Linux, whichever may already be in use in the radio station.

• No CPU scaling: CPU scaling is enabled by default in most systems. This means that if a computer normally runs at 533 MHz, it can be over-clocked to almost 1 GHz if required. This scaling normally happens automatically using different governor algorithms when the CPU utilization increases beyond some pre-defined threshold. We noticed two disadvantages with CPU scaling though. One, the act of scaling caused disturbances in the audio quality. Second, running the CPU at a higher frequency would increase its temperature, and a watchdog would then shut down the computer when the temperature got too high. It is worth mentioning how we identified these issues though.

We monitor audio quality in an automated manner by generating a sine wave at a fixed frequency, and then draw the audio output into a another computer where we observe the primary frequency component of the audio being received. In a perfect transmission, we would get a single peak on the same frequency at which the input sine wave was generated. But we found that at exactly the times when the CPU would scale to a higher frequency, we would miss out some audio samples. So the scaling itself was not happening smoothly.

The temperature issue was even more interesting. Everything would work perfectly if we tested our system during the day. But interestingly, if we would leave it running all night, playing and archiving audio just to do a stress test on the robustness, very often the temperatures would rise and the CPU would freeze. We finally figured that this was happening because during the day we would have the air-conditioning turned ON in our office, but at night, since the hot Indian summers are rapidly setting in, the room temperature would rise and the CPU would get too hot!

As a safeguard, we have therefore disabled CPU scaling. We found that it was not required anyways, except maybe when we would encode a wav file into an mp3, because the encoder would take a lot of CPU. However, we do this encoding lazily and therefore it is not critical if it gets done in 30 seconds or 1 minute. We actually monitor the idle state of the system, and if it has been idle for more than a prespecified time interval, it is only then that we initiate an encoding operation.

• Log shipping and upgrades: Until the time we do not build systems for Internet connectivity of the radio station, we have designed a low-tech method for remote maintenance. Whenever a USB key is inserted into our box, all system logs get copied on to this USB key. And if the key is brought over to a city that has Internet connectivity, and inserted in a computer connected to the Internet, then our software automatically picks up the logs and mails them to us. We can then analyze these logs, check for any errors, and if an upgrade is required, then copy a patch to the same USB key. When this key is now inserted back into the box at the radio station, the upgrade is performed automatically. Thus, unless there are some serious hardware errors which may require our attention, software errors and bugs can be handled through this USB transport system without requiring us to visit the radio station.

• Service oriented design: All of audio broadcast, archiving, library search, and telephony are named as “services” in our system. An easy way to understand this concept is that our platform provides certain “services”, and applications can be written which use these services. Each service exposes an API to the basic functions it provdes, and applications use this API for their custom functionality. Anybody can then write an application using this high-level API without having to worry about the internals of audio playout or telephony, etc. In fact, we plan to work with students in various places to have them conceptualize and write all sorts of different applications.

Meeting the goals

We are extremely confident that our system design will be able to meet the goals outlined above.

• Our one-box setup is as low-cost as it gets. The mini-ITX box with a hard disk costs around $300, plus an extra good quality USB soundcard for $50. We will keep adding new components over time such as an FXO telephony card, a WiFi card, and an FM transmitter card, but the costs should hopefully remain under $1000. The software is of course going to be free!

• Having a fan-less box, and canceling CPU scaling, should help our system cope with the challenging climatic conditions of India.

• Java brings in platform independence.

• The plug-n-play and service oriented design makes our system incrementally deployable. It can be simply plugged into any radio station setup, and services for audio broadcast, archiving, library, or telephony can be turned ON and OFF as desired.

• The plug-n-play characteristic of our system also helps keep the installation and configuration process simple. Users just have to plug in audio cables from the right sockets of their mixers into the soundcards mounted on our system.

• Log shipping and automated patching of upgrades through a USB key will enable remote maintenance, albeit at the cost of a delayed response because somebody will have to physically transport the USB key to an Internet connection point. But we feel this should be good enough for now. Besides, since our system will be loosely integrated with a radio station setup, any downtime will not bring the station off the air because basic audio broadcast can still be done using common software such as winamp.

• Low power consuming: Our choice of Via and Soekris single board computers definitely helps to keep the power requirements low.

• Platform based design: We have designed our software in a service oriented manner right from the start. This makes it extremely versatile to be used for many different kinds of applications.

Do stay tuned for more updates. We have our first release scheduled for May. Until then, all of us at Gram Vaani are busy writing code like monkeys! And stress testing our system using brute force like donkeys! But the most interesting part of this project has been of how we have this extremely broad vision of enabling community media to empower people, and how it actually technologically boils down to very detailed nuances of figuring out audio quality and CPU temperature and log shipping, etc. This kind of a unified activity spanning the entire stack from vision to implementation is rarely seen in technology projects, and this is really what inspires our team of how we can make a positive impact on the world through technology.