2 Ways in Which a WebRTC P2P CDN can Assist Internet Radio Stations?

WebRTC can fit nicely into interesting use cases. Radio broadcasting is one such use case.
Two things happened that budged me towards writing this post:
- A story about Norway ditching FM radio, going all digital
- Sitting for a talk with Hadar Weiss, Co-founder and CEO of Peer5
The challenge of Radio stations in the Internet age
Radio stations are moving towards the digital world. Part of it may be replacing broadcast channels from analog ones to digital ones, but a lot of it has to do with streaming over the internet. To do that, just like with the case of video over the internet, the media needs to be broadcasted. In Internet terms, that's sending a stream to each and every person listening to the station. The more people listening, the more servers and bandwidth will be required. A common scenario will take a successful radio station into the internet. They will open up a website for the station. Push their scheduling through it, enable forums and open up streaming to the audience. A few of their listeners will decide open up their web browser at work to listen in, keeping the web page open for the whole day. Life is good. There are masses of listeners on FM and a couple thousands over the internet. The server streams nicely. Everyone is happy. One day, the marketing guy of the station has an epiphany - why not have a mobile app for the radio station? They outsource the development of such an app, and put some nice bells and whistles. When the day comes for the launch, they promote the hell out of it running ads on their radio station throughout the day. The thousands of listeners they had over the internet? They become tens of thousands the next morning. The server crashes from the load of it all. True story.Where WebRTC fits in radio
Where can WebRTC help? With its data channel, having it augment a CDN. WebRTC in this use case, brings with it some interesting benefits/features:1. Longer streaming sessions
Listeners stay tuned in to the station for longer periods of time. It happens because the user experience improves due to the use of WebRTC. The great thing about a radio station is that everyone listens to the same thing. It is "real time" - a slight delay of up to 30 seconds is usually built into it. With regular CDNs and streaming servers, the browsers may experience periods when they pause while buffering incoming data. WebRTC enables reducing the probability of buffering by using prefetching, where the next couple of seconds, or even the next song, are side-loaded from other listeners. If the radio station halts less, you will not be inclined to leave because of a bad experience.2. Increased audience size for the same hardware
If you plan on getting more people to your station over the internet, or via your mobile app, you better be prepared. That means making sure you have a big enough operation running with a CDN in place or enough media servers to back up the demand. WebRTC here can act as an insurance policy and as an optimizer of your server's capacity. Radio has some interesting characteristics:- Everyone tuning in to the station listen to the same media stream
- Many of the listeners are from the same geographic area


As U.S. spectrum gets increasingly crowded coupled with a trend to deregulate government agencies like the FCC, WebRTC for streaming radio content will become more widely used.
Norway's switching from FM broadcast radio to DAB broadcast radio. So WebRTC isn't relevant for that.
P2P has been tried before - by me, among other people - and the main issue is that it needs specific code to receive it. The same goes for WebRTC, I guess, too.
10,000 listeners is a LOT for an internet radio station, by the way. Most do a fraction of that.
James,
While not directly connected, there is a move towards digital broadcast. Done over the internet instead of the airwaves means that WebRTC can play a role.
As for WebRTC - the beauty here is that the specific code being received is taken care of by the browser already with little effort on the broadcaster's side in changes to his current streaming setup for the internet.
I was expected James to reply here, but since he hasn't, I'll paraphrase the discussion we had privately:
1) Broadcast is totally different to online, so Internet really isn't broadcast. To get the same economies of scale and so on, you'd need multicast technology - all possible, but few ISPs support it and we're well outside the realms of what WebRTC can provide, sadly.
2) I thought that browser support would have a useful impact on radio as well; however not only are there relatively few listeners online, but most of them listen using hardware "internet radios", like the Pure Evoke Flow or Q2 WiFi Radio - these very much don't support WebRTC.
I use boombox.online they have many features ad browsers support
10,000 listeners is a LOT for an internet radio station, by the way. Most do a fraction of that.
Thanks for sharing Mike.
hii sir ,
can you please tell ,which technology use by his app for audio stremming (Dose FM)(https://play.google.com/store/apps/details?id=com.doseapp&hl=en_IN)
in this app anyone broadcast your show and other also join the using using permission of host. it's possible to implement without webrtc?
I have no clue if it uses WebRTC or not.
Thefunctionality you describe can be implemented with WebRTC.