Why the player on your site has gone quiet
Your player is quiet because the page is secure and the stream is not. When a page arrives over HTTPS, anything it pulls in over plain HTTP is called mixed content, and browsers no longer simply play it. MDN's guide explains the reason: anything fetched without encryption can be read or altered by someone on the network between the listener and your server, which undoes the protection the page itself was given.
Audio sits in the gentler of the two groups the W3C Mixed Content specification defines. Audio, video and images are upgradeable: the browser changes the http:// in the address to https:// and asks again. Scripts, frames and data requested with fetch() or XMLHttpRequest are blockable: they are refused without a second try.
The Chromium blog announced that from Chrome 80, mixed audio and video are upgraded to https:// and blocked by default when they fail to load that way. Mozilla announced the same treatment for Firefox from version 127, where an upgraded audio or video request that HTTPS cannot answer is not loaded. MDN also notes that blocking all mixed content is the default in Safari. Whichever browser your listeners use, an address that only speaks plain HTTP ends in silence.
What happens to each kind of stream link
Where the link sits and how it is written decide what the browser does with it. These are the cases station owners run into most, each from the documentation listed under sources.
| Your link or player | On an https:// page | Documented by |
|---|---|---|
An audio tag whose source is http://name:port/stream | Chrome and Firefox request it again with https:// in place of http://; it plays only if your server answers over TLS | W3C spec, MDN, Chromium and Mozilla blogs |
An http:// link built on an IP address, such as http://203.0.113.10:8000/stream | Not upgraded, so it is blocked | W3C spec (upgrade algorithm), MDN |
A player script that loads the stream or the song titles with fetch() or XMLHttpRequest | Blockable content, refused | W3C spec, MDN |
| A player embedded with an iframe whose page is http:// | Blockable content, refused | MDN |
An audio tag carrying the crossorigin attribute | The spec's prose says CORS-enabled mixed requests are force-failed (its example is an image with crossorigin); don't count on this one being upgraded | W3C spec |
| An Android app built for Android 9 (API level 28) or later | Plain HTTP is disabled by default unless the app opts in | Android network security configuration |
Our reading: the W3C spec excludes top-level navigations from mixed content checks, so the http:// address typed into the address bar is not mixed content and may still play, while the same address inside your https:// page is.
Two ways to get a secure stream, and what each asks of you
You either run TLS on the streaming server yourself, or you stream from a host that already answers on https://. Either way the fix is the same thing MDN recommends for any site: serve the resource itself over HTTPS and change your links to match.
Doing it on your own Icecast server. The Icecast 2.4.1 configuration reference says HTTPS on a listen socket needs Icecast built against OpenSSL, the ssl option set to 1 on that socket, and an ssl-certificate file that holds both the private key and the public certificate, readable by the user Icecast runs as. Keeping that certificate valid is your job from then on.
Streaming from a host that answers over HTTPS. The host owns the domain and the certificate, and you paste the link it gives you. For a station whose only goal is to be heard, this is usually the shorter road, and it is the one the rest of this page walks through.
How a Primcast station gives you the secure link
SSL radio streaming at Primcast is part of every station, on all three plans, Free included, with nothing to add at checkout. For a station in New York, the listen link has the form https://ny1.radio.primcast.com/port/stream, with your station's own port in place of the word port (a Bucharest station shows its own server name). The radio panel prints the complete link on its Overview and Share tabs, so you never have to assemble it.
- No certificate work. The stream runs on Primcast's radio domain, and the certificate behind it is Primcast's to look after. You buy, upload and renew nothing.
- Your encoder carries on as before. Only listening moves to https://. The server, port and password on the Go live tab stay the same, and Icecast and SHOUTcast encoders both connect.
- One place for everything you share. The Share tab holds the https:// link, a player to paste into a web page, and your station's public page with its show line-up. Once Primcast approves it, the station is listed in Primcast Tune In.
- The same link on every plan. Moving up to Premium or Platinum leaves the link unchanged, so nobody has to update a bookmark or an app.
If you are choosing a server type, the Icecast hosting page covers the server every new station starts on and its encoder settings, and the SHOUTcast hosting page explains switching your station to a SHOUTcast DNAS 2.6 server from the panel.
Moving your station's links over, in order
Changing the link is quick; finding every place the old one lives takes longer. Work through it in this order:
- Open a station from the radio plans, point your encoder at the server, port and password shown on the Go live tab, and check the stream is on air.
- Copy the https:// listen link from the Overview or Share tab.
- Replace the player on your website with the one from the Share tab, or put the https:// link into your own player. Change every http:// reference, including any address the player uses for song titles.
- Load your site over https://, open the browser's developer console and look for mixed content messages. MDN points to the console for exactly this check; a clean console and sound from the speakers mean you are done.
- Update the link in your apps, social profiles and every radio directory that lists you. The radio page says the panel helps with getting into TuneIn and other directories and checks that each one plays your current address.
When the plain http:// link still earns its keep
Some listeners use gear that cannot open https:// at all. For them the panel lists a plain http:// copy of the same link under For older players, aimed at Winamp, hardware radios and old software. On Platinum, the radio CDN link has a plain http:// copy too.
Hand that copy only to the device that needs it, and keep the https:// link for websites, apps, messages and directories. One thing does not work on either: an http:// address made from your station's IP address and port is refused when typed straight into a player.
What a secure link will not change
HTTPS decides whether your stream is allowed to play; it does not decide how many people can hear it or how good it sounds. Those are set by the plan: how many listeners can tune in at the same time, the highest bitrate your encoder may send, and whether Auto DJ keeps the station on air while nobody is live. If listeners are spread across continents, closest-server delivery through the radio CDN comes with Platinum only; Free and Premium stations are reached on the server they live on.
Questions people ask
- Why does my stream play in a new tab but not in the player on my site?
- Our reading: the W3C spec excludes top-level navigations from mixed content checks, so the http:// address opened on its own in a tab is not mixed content and may still play, while the same address inside your https:// page is. There, Chrome and Firefox upgrade it to https:// and drop it when that fails. An https:// listen link removes the difference.
- Is the secure link an add-on I pay extra for?
- No. Every Primcast station has the https:// link and the player, on the free plan as well as Premium and Platinum, and Premium and Platinum use exactly the same secure link. The plans differ in listeners, sound quality and Auto DJ, not in HTTPS.
- Do I have to get my own certificate or domain?
- No. Your stream runs on Primcast's radio domain and the certificate belongs to Primcast to look after. There is nothing for you to buy, upload or renew.
- My station uses a SHOUTcast encoder. Will it still connect?
- Yes. Only the listening side becomes https://. Your encoder connects with the server, port and password from the Go live tab, whether it is an Icecast or a SHOUTcast encoder.
- Can listeners with Winamp or an internet radio set still tune in?
- Yes. The panel lists a plain http:// copy of your link under For older players for software and hardware that cannot open https://. Share the https:// link everywhere else.
- Will the link change if I move to a bigger plan later?
- No. The link stays the same when you change plans, so nobody has to update a bookmark or an app. What changes is how many people can listen at once and the quality you can send.