For a version of this article that refers to live streaming, see Why does my stream not start immediately after I press Play?
The actual delay that occurs when you hit Play depends on a few things. Broadly speaking, the delay is mainly due to information processing related to advertising data and the latency between the podcast app and the server.
Let’s walk through the process:
Listener presses Play in their podcast app or embed player on a website. The player makes a request to the enclosure URL for the episode. If one or more measurement prefix URLs are configured, then each prefix will redirect to the next.
The Omny Studio servers receive the request, validate it, and determine where to forward the download request to. Omny Studio supports a number of configurations, including support for ad injection. These options are validated, and the request is redirected to the CDN that will serve the download. In this case, assume the request is redirect to the Triton podcast CDN. This request typically takes a few hundred milliseconds to process.
The Triton servers receive the podcast download request and create a profile of the user. Because Triton supports ad insertion, we need to process any listener profile information before we can return any audio to the player. After the download request hits our servers, our profile enrichment determines any relevant information based on attributes of the request such as location and data segments, and may include first-party data (gender, age, etc.) if passed by custom podcast apps.
The Triton ad server then takes the profile and content information and selects the appropriate ads to include in the podcast. The number of ads, and their positions, are configured by ad markers added to the episode in Omny Studio.
At the same time, the stitching server downloads a local copy of the podcast audio if it doesn’t already have one. This process can take some time, and delays the start of your download, but generally is a one-off cost paid for the first download request. The podcast audio expires from this local cache based on the download usage; once this happens any subsequent download request will force the file to be fetched again.
If ads are returned, they are stitched into the podcast audio and the resulting audio file is served to the podcast app or embed player.
The podcast app or embed player receives the stream, accumulates enough data for a sufficient buffer, and starts to play. It typically takes several seconds to download enough of the audio file to fill this initial buffer and for playback to start. Some players wait for a relatively large amount of audio to buffer before playing, so the amount of time this step takes is variable. Note that the buffering for embed players is controlled by the browser, not the player. Each brand of browser uses its own method; if you consistently have a long wait time for podcasts to start up in an embed player, try using a different browser.
Some important notes:
Steps 3 and 4 always occur, even if there are are no active campaigns, as the profile enrichment must take place for ad selection.
Steps 3 to 5 require internal Triton services to communicate between each other and are usually very fast but can still take as long as a second or so.
Steps 1 and 7 are subject to the listener's network latency and are affected by their proximity to the Triton and Omny Studio servers. Downloads are also always served over HTTPS, which has a small overhead.
When you combine steps 1 to 7, a realistic expectation for audio to start playing is 1-4 seconds, although we are always striving to make it faster.
If you see consistent delays over 4 seconds, it might be necessary to run some analyses to understand in which of the six steps the delay is generated. As a starting point, you can ask your engineers or technical analysts to run some tests using Chrome, Safari, or Firefox inspectors before calling Triton support.