How to get your radio station listed in iTunes Radio
A good way to make your radio station known to a broader audience and attract global listeners is to have it listed in directories. In this post we’ll walk you through the process of registering your radio station with iTunes. It’s an easy and worthwhile procedure that will gradually bring you a fair amount of new listeners.
Pro DJs: using the gear of your choice on Radiojar
Radiojar provides a fully web-based environment that allows live audio mixing and the use of you computer’s microphone through our Virtual Studio console.
However, we know that pro DJs will need to be able to use the gear they love to achieve maximum performance. Radiojar fully integrates with any DJing software that’s compatible with Icecast and is able to stream in the OGG format. So, whether you prefer Traktor, VirtualDJ, Sam Broadcaster, Mixxx or any other similar software, you can use it to seamlessly connect to Radiojar and stream live from your computer.
When you schedule a radio show, you’ll receive instructions on the Radiojar homepage on how to adjust the connection settings in your tool of choice. Do not worry about introducing noises or interruptions to your station’s live broadcast when switching streams. Radiojar will automatically fade in or out smoothly.
* We have noticed that VirtualDJ’s latest version has a buggy Icecast connector which results in getting disconnected when there is silence from your side.
We’re live! Private beta begins
After a busy spring & summer, we’re happy to announce that we’re entering private beta. In the past year, Radiojar’s DJing platform has been tried by more than 15K users, through our Facebook demo games, the MTV/Crunch “Poke the DJ” competition, and neolaia.gr’s radio. The most popular of the DJs who used our Facebook games are getting an invite for radiojar.com, as promised (Bonus: sign in with your Facebook account and you’ll find your music library waiting for you on radiojar.com!). Those that have signed up for a DJ invite on radiojar.com will be getting theirs next. If you haven’t signed up yet, now is a good time.
Once you’ve set up a DJ profile on radiojar.com, you can create shows and host them on any of the radio stations that will allow you to (we’ve set up a few trial ones for you).
Creating & running a radio station on radiojar.com is fully functional as well. If you’re interested in giving it a test drive, we’ll be happy to provide you with a voucher that will allow you to experiment with it for a few weeks. After that time, our normal pricing policy will apply, (prices are reduced by 50% during the beta period). Please contact us to arrange it. We’re thrilled to be ready to host more radio stations!
We’d like to extend a big thank you to all our alpha users who helped us test and shape radiojar.com as it is today, especially Milk and Chocolate, Best Radio 92.6, Nikos Garavelas, neolaia.gr, 696radio and ECM/Mikri Arktos.
1, 2… is this thing on?
We’ve been busy these last few months: Radiojar was invited to pitch at HackFwd’s Build 0.9 “Pitch in Berlin” and at MUSIC TechPitch 4.5 in London back in March, at the Balkan Venture Forum in April where we were finalists for the next European Venture Summit and then at Google’s “Music Comes to Campus” event in London, in June.
We’ve gathered some valuable feedback along the way, made some good friends, started out with some great new clients and we’ve been hard at work developing the Radiojar platform.
Summer has flown by and this will be an interesting autumn, big announcement coming very soon :-)
Meet us at Midem 2012
We are thrilled to announce that Radiojar will be visiting the Midem fair in Cannes next weekend (28 to 31 January) to meet with some of the tech pioneers of the music industry. If you are interested in meeting up, get in touch.
About Midem: Midem 2012 brings together music makers, cutting-edge technologies, brands and talent to enrich the passionate relationship between people and music and transform audience engagement.
Cloud management over the cloud
One of the most important challenges we are facing at Radiojar, is the effective management of components that assemble this service platform. Radiojar as a platform virtualises all necessary components a web radio station needs to work. To name but a few: radio servers, radio automation, media library, virtual studio, streaming servers, webcasters, web apps etc. Each service has different needs in hardware resources. Most can work on their own but at the same time collaborate with other services. The architecture we envisioned would support independent services running from managed or unmanaged cloud instances and use a central “intelligent” system to control them, order them, check their health and expand them if needed.
This system has to be scalable, efficient and robust. Scalable means able to serve as many clients as demand dictates at any given time. Efficient means able to utilise all available resources to their full extent, which in turn leads to cost effectiveness, making the solution affordable and viable. Finally, robust means fail-proof, with low maintenance requirements, flexible configuration options and adaptability to various environments.
Service management in Radiojar
So, what we’re designing is a piece of software that runs on the web and can be triggered to perform certain tasks in given situations. Its major responsibilities are to track all running services and available resources, to expand the cloud with new hardware resources as needed, to register and unregister services and to delegate commands and pass configurations to running components. This is the component we’re calling Radiojar Manager.
The Radiojar Manager has a RESTful API that most components use for their communication. All services are unaware of their neighbours and there is no direct connection between them, they’re connected through the manager. Communication works both ways, components are able to receive and transmit status and commands related to their function. There are also some components that are completely unaware of being managed: these are what we call workers and they are designed to do specific tasks in a cloud computing environment but can be remotely turned off and on.
What we have achieved with the Radiojar Manager is to be able to have any number of components that we can combine to deliver a configurable solution. This solution can be robust, flexible and -most importantly- work in a self-managing manner, which is our ultimate goal for the Radiojar platform as a whole.
Chosing a hosting environment
With this concept in mind, we started looking for the best way to host the servers on which Radiojar’s infrastructure software will run. Research led us to Rackspace Cloud Servers. Its most appealing feature was the RESTful API, which allows for customised and automated management of our servers.
While these servers suit us for most of Radiojar’s components, there are cases where these virtual instances are not fit for our purposes. In such cases, we want to be to able to lease other servers from other providers. Of course we won’t be able to remotely manage the hardware of these servers but the services they run will be managed by the Radiojar Manager.
We chose to host the key component, the Radiojar Manager itself, on Google AppEngine which meets all aforementioned criteria. Infinite scalability, persistence and as reliability. It was a difficult and critical decision since we are creating another overhead which is security (yet another post to come). We also chose Java as a language of implementation instead of Python, mostly because of the open source resources that we found which could speed up our work.
Automatically expanding clouds
So we need to manage a cloud of servers (Rackspace Cloud Servers) from another cloud server (Google AppEngine). The goal is to create a system that will automate tasks that would otherwise have to be carried out by system administrators. When a new project has to be created, the system will communicate with Rackspace’s cloud service and automatically deploy and set up all necessary instances and services.
The connecting link between these platforms is Rackspace’s RESTful API. Since the Radiojar Manager is implemented as a Java project, we had to choose a framework that will make our lives easier when working with RESTful web services. Apache CXF was chosen for this purpose mainly because of our previous experience with it. We then created a library providing a Java binding for Rackspace’s API.
The most interesting feature of CXF was a WADL-based source code generator. Rackspace provides a WADL document for its web services and this served as a good test case for the generator. We ended up patching CXF’s source code to make it work, and submitted these changes contributing back to CXF (they are now part of the project). The result was worth the effort: instead of writing the required Java stub interfaces by hand, we generate them in seconds -and this can be done for any WADL-described RESTful web service. Of course, integration of the binding library into Google’s AppEngine had its quirks and in order to make everything work as expected we had to dedicate a considerable amount of time. In the spirit of open source code -and since most of our work is built over a collection of open source projects- we plan to release the binding library as an open source project too, after applying the necessary polish on the source code.
We are ready to jam
The Radiojar Manager is now in a condition to connect the dots between the numerous components in our platform. The amazing part of this component that acts as the heart of our platform, is that it has the intelligence to act according to feedback and demand, and at the same time it can be easily extended via web calls to include even more independent systems.
Handling Media Libraries
At the core of Radiojar is the music library, the place where music tracks are stored. It has to be able to power anything from fully private user-managed libraries, to fixed-content shared libraries for thematic radio stations and everything in between, so it needs to be extra flexible and efficient. A music library is made up of three things: a database that stores the tracks’ meta-data and allows searching the library, the actual music tracks, and a set of additional related files (e.g. transcoded versions, waveform preview images). It needs to be private (some DJs don’t want anyone else to see their hard to find exclusive tracks!) and secure (it must shield audio files form being downloaded by end users, all media must only be played through a streaming server).
Right now, there are two different library architectures in use on Radiojar. One is using an SQLite farm and the other is using NoSQL technology. Our requirements were, as mentioned: security, search speed and scalability, but we also needed to find a solution that will be cost-effective as Radiojar grows: we want it to be able to handle TBs of data and hundreds of thousands of DJs.
SQLite farms
We started using a simple farm of servers running SQLite and offering basic file storage. We used Python for the managing processes and the Django framework to implement RESTful access. We create one folder for every DJ or radio station in which both the database and the binary files are stored. A “farm manager” is responsible for distributing these files across server instances, in a process that is transparent to the end user.
SQLite is the fastest database provider for small numbers of records, so having a single database per user has quite impressive results in search speed. A nice side effect of this architecture is that any data loss would end up affecting only a few users. Also, this solution makes user libraries distinct and portable. Scaling up is also easy: to increase storage and user capacity, we just add more servers. Another advantage is that servers don’t need to be under the same cluster. They can be anywhere, which makes this solution flexible and cost-effective.
On the downside, the upload process is slow, because we need to process each track individually to create waveforms, normalize, analyze, verify etc. Also, taking backups is a complicated process (because of the binary files being distributed across a number of servers) but it’s been automated.
Our biggest issue with this architecture was that it could never support large shared libraries. This led us to our next solution which is cloud-based file storage combined with NoSQL meta-data storage.
Managing Rackspace Cloud Files with Google App Engine
Firstly, we needed to find a cloud storage provider. After much research we came to the conclusion that Rackspace Cloud Files is actually cheaper from other providers for our type of usage (big files, infrequent access). Since we had already started with Rackspace Cloud Servers for our live streaming radio servers, it was easy to integrate.
For the database we chose Google’s App Engine and its NoSql technology, mostly for its cost-effectiveness: It can be as scalable as we can afford. App Engine has many tricks but also many advantages, and since we had started working on Python wrappers the transition was quite easy.
The major challenges were in finding a way to process audio files (can’t do that on App Engine or Cloud Files) and in limiting the bandwidth used on Cloud Files and App Engines as much as possible to minimise cost. As previously mentioned, music tracks are analyzed, transcoded etc. upon uploading, so a middleware layer was introduced to handle this processing. In order to keep the system scalable, this middleware was created as a standalone system that also lives in the cloud. We are using Rackspace Cloud Server instances for that, which not only handle the file processing, but also act as proxies for the binaries stored in Cloud Files. This way we can simultaneously process a great number of files and also restrict any access to the binaries except from our own radio servers. These Rackspace Cloud instances are managed from a custom server manager built in Java that also runs on Google App Engine (but that’s a topic for another blog post).
This solution offers us unlimited storage that comes with a “pay as you go” price tag, so it’s great for bootstrapping. It can grow with us while providing a fail-proof, enterprise level infrastructure right from the start. The library search speed that we were getting from App Engine was an issue here, but we are talking about unlimited memcached 1GB pages, so is just a matter of good implementation and fine tuning. Our middleware allows us to add library features in a plug-in like way, for example Echonest data integration, or audio normalization.
We’ve been testing this architecture for 2 months and it was also used in our first commercial case study. Now it’s being used in all new Radiojar projects. We’re still using the SQLite farm architecture, for customers that want more closed solutions and don’t feel at ease with their data on the cloud.
Radiojar’s key feature is the virtual studio. It allows real-time online mixing through the web browser. All mixing occurs on the server side, so DJs can mix tracks from anywhere in the world and add their voice as well. Even if internet connectivity is lost during a live session, the show goes on through a playlist. Even if the playlist is empty, Radiojar will continue playing automatically, trying to carry on in the same style of music until the active DJ can connect again and resume playing.
In the next few posts we will talk more about the technology that’s used behind the scenes to power this functionality.
MTV “Poke the DJ” by CRUNCH is powered by Radiojar
Our latest project “Poke the DJ” is live, a collaboration with MTV Greece and Nestlé’s Crunch chocolate bar.
“Poke the DJ” is based on Radiojar’s cloud streaming & virtual console technologies to power a themed radio station and DJ competition on Facebook. Aspiring DJs do live shows on this radio station and compete for the most “likes” to get a chance to do a show on MTV Greece’s TV channel and win professional DJing equipment!
