For a version of this article that refers to podcasting, see Why does my podcast not start immediately after I press Play?
Triton supports a broad range of live streaming use cases, so the actual delay that occurs when you hit Play depends on a few things. Broadly speaking, the regular delay is mainly due to information processing related to advertising data and the latency between the client player and the server.
Let’s walk through the process:
Listener presses Play on their player. At this point, the player will have gathered basic information about the listener and added it to the stream request that it prepares to send to Triton. However, there might be additional information gathered by the player before making that call. This can range from adding an ad ID to adding a large collection of data that includes registration data for the listener.
The Triton servers receive the stream request and create a profile of the user. Because Triton supports ad insertion, we need to process all of the listener profile information before we can return any audio to the player. So after the stream request hits our servers, our profile enrichment server matches all of the data sent from the player to valuable enrichment information such as location, data segments, first-party data (gender, age, etc.). All of the things that add value to a stream need to be processed immediately so that it can be used for ad selection (pre-rolls and/or mid-rolls).
The Triton ad server then takes the profile information and finds an appropriate ad to play for the listener.
If a pre-roll is available and scheduled, the ad is then stitched into the stream and the stream is sent to the listener’s player.
The player receives the stream, accumulates enough data for a sufficient buffer, and starts to play. This time buffer is typically just a few seconds but can be longer, in which case it is downloaded in an initial burst of data that takes just a few seconds to build the buffer. On most players the delay should be barely perceptible, if at all.
Some important notes:
Steps 2, 3, and 4 are skipped for stations that do not use ad insertion or listener profile enrichment.
Steps 2 and 3 occur even if there is no pre-roll, because the profile information and ad selection always take place even when there is no pre-roll.
Steps 2 to 4 requires 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 5 are subject to Internet speed and latency. HTTPS connections require a lot of back and forth, so a higher latency between the client and the server results in more delays before the stream can start. This is variable and can sometimes be significant.
When you combine steps 1 to 5, a realistic expectation on steam start is 1-2 seconds, although we are always striving to make it faster.
Our services are optimized to provide a good experience to local listeners who are close to the location of your stations. However, if you have listeners on the other side of the world, they will experience more delay before their stream starts.
If you see consistent delays over 2-3 seconds, it might be necessary to run some analyses to understand in which of the five 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.
As noted at the beginning, all of this is highly variable. Triton can deliver streams with no ads that start up nearly instantaneously. Some players may include other steps before or after calling Triton services, which might create additional delays. And, of course, all connections are subject to the nature of the Internet links between two locations.