I was just listening to Spotify, and my internet connection went down. While I was not surprised it still completed the song (due to buffering), I was surprised when it went on to the next one and keep playing for several minutes (and then I got internet back).
How long can Spotify continue playing after connection is lost? Assume no files are "enabled offline".
The task may be harder to analyse than just "time it"
Spotify will cache previously played songs, so if one of those is playing when your line goes down, it's already on your device, so you won't even notice.
As to exactly how large the buffer is at any given time - it auto-adjusts & it can be anywhere from 15s to an entire song, depending on its source, peer or server [see below]
I've included these articles just for further reading - too much to précis here, but give reasonably simplified explanations.
Spotify For Dummies has a good article on the cache & how to adjust its size
Spotify Technology: How Spotify Works has some simple info on how the streaming technology works.
I did find the authoritative document on the subject, written by Gunnar Kreitz & Fredrik Niemelä...
Spotify – Large Scale, Low Latency, P2P Music-on-Demand Streaming
Extract:
A given track can be simultaneously downloaded from the server and several different peers. If a peer is too slow in satisfying a request, the request is resent to another peer or, if getting the data has become too urgent, to the server.
While streaming from a server, clients throttle their requests such that they do not get more than approximately 15 seconds ahead of the current playback point, if there are peers available for the track. When downloading from the peer-to-peer network, no such throttling occurs and the client attempts to download the entire currently playing track. If a user changes tracks, requests relating to the current track are aborted.
Files served within the peer-to-peer network are split into chunks of 16 kB. When determining which peers to request chunks from, the client sorts peers by their expected download times (computed as the number of bytes of outstanding requests from the peer, divided by the average download speed received from that peer) and greedily requests the most urgent chunk from the peer with the lowest estimated download time (and then updates the expected download times). This means that chunks of a track are requested in sequential order. As all peers serving a file have the entire file, requesting blocks in-order does not affect availability or download speeds.
A client can at most have outstanding requests from a given peer for data it believes the peer can deliver within 2 seconds. An exception to this is that it is always allowed to have requests for 32 kB outstanding from a peer. If the estimated download time for a block exceeds the point in time at which the block is needed, that block is not requested.…
Spotify clients do not limit the buffer size, and thus the crux of the problem is the appropriate modeling of the channel and using that information to adjust the initial playback latency. As a simplification, the client only considers the channel to the server for latency adjustment.
Spotify clients use a Markovian model for throughput as observed by the client (i.e., affected by packed delay variation, packet loss, and TCP congestion control). Clients make observations of throughput achieved while it is downloading from the server to estimate a Markov chain. Only data collected during the last 15 minutes of downloading is kept and used. The states of the Markov chain is the throughput during 1 second, discretized to 33 distinct levels between 0 and 153 kBps (more granular at lower throughputs).
The model is not used to compute an explicit playback latency. Instead, before playback has commenced, the client periodically uses the Markov chain to simulate the playback of the track, beginning with the current amount of buffered data, and the current data throughput. Each such simulation is considered as failing or passing, depending on if an underrun occurred or not. The client performs 100 simulations and if more than one of them fails, it waits longer before beginning playback. During these simulations the client makes the simplifying assumption that data is consumed at a constant rate despite the fact that the codec used has a variable bitrate encoding.
