Almost everyone else gets the MP3 version, except a few apps on KaiOS which gets the Opus version. (You’ll be surprised just how good the 16kbps version sounds, I’ll bet).Īpps that are on an allowlist get the AAC version. Learning: produce multiple pieces of audioĪn AAC-HE file at 56kbps (stereo) at -16 LUFSĪn Opus file at 16kbps (mono) at -14 LUFS Because I also support PodPing, services connected to that also see new episodes almost immediately. Literally, I press the publish button in my own code, it informs the hub, I look at my phone, and there’s the new podcast. So, when I publish a new podcast, it appears on Google Podcasts instantly, since Google uses WebSub. I’ll tell Bill over there, and Bill will give you a call, OK? Go give him your telephone number.” WebSub or PodPing are the computer equivalent of me telling you: “Stop asking me all the time whether I’ve something new for you. It’s very wasteful in terms of bandwidth, too. While I can influence the “every so often”, I’ve no actual control over when Apple, or anyone else, comes back to check. The way RSS feeds work is that someone like Apple Podcasts comes along every so often to check whether I’ve just added a new podcast. Overcast, Google and PodcastAddict check roughly every four minutes. The RSS stats page shows when podcast aggregator apps come to check on my RSS feed. In a typical day, that feed sees 460 different useragents, and 86% of my RSS feeds are still cached by Cloudfront. This is normally a bad thing for caching, but RSS is a little different, given that there’s a finite amount of useragents for RSS feeds. I produce a different version of the RSS feed for each user-agent (so that I can do some fancy monitoring).
Podnews’s main RSS feed is served just over 19,000 times a day a total of 1.6GB of data. The RSS feed is therefore cached on Cloudfront and is normally fed to clients in a compressed format. This gets hit many, many times and is quite a large file. The RSS feedĪ podcast needs an RSS feed, of course, to function. Our podcast stats page calculates the cost of serving our audio. Some areas are significantly more expensive. Additionally, you can keep pricing down by restricting Cloudfront to US/EU only. This has already been useful (in the early days, I was serving audio from the webserver, rather than S3).įor the US and Europe, where the majority of my traffic is, Cloudfront is a little cheaper in terms of bandwidth, too.
This allows me to switch, if I want to, from Amazon S3 to somewhere else to host the audio - and keep the URL the same. By piping all my traffic through Cloudfront, I have one simple logfile regardless of where all the stuff is.Ĭloudfront’s “behaviours” allow you to direct different URL patterns to different origin servers, too.
SELF HOSTED RSS DOWNLOAD
Secondly, when using tools like WebSub or PodPing to “announce” to podcast apps that you’ve a new episode ready, traffic can be quite hard work for a server as potentially hundreds of podcast apps all jump to download the audio as soon as they can.Ĭloudfront also keeps its own logs, and can be configured to drop them all into an Amazon S3 bucket for analysis later. Speed is now important for audio, so a CDN becomes useful. Suddenly, it’s important to burst-deliver the first bit of a podcast as quick as you can (to lessen the wait between hitting “play” and hearing the audio). Things have changed, though: most notably, the advent of Google Podcasts and smart speakers, both of which don’t download but rather stream podcast audio on-demand. Most people get their podcasts automatically downloaded overnight, for example, and fast speed or even a consistent transfer rate isn’t necessary if you’re downloading unattended. I used to think that a content delivery network like Cloudfront wasn’t necessary for a podcast. (Here are all the tools I use.) Learning: use a content delivery service for audio (Fill this in now you won’t lose your place!)
0 kommentar(er)
