42. Audio streaming and podcasts

The archetype. An app in which people listen to music, spoken episodes or live radio for long stretches, mostly with the screen off, and expect the same queue, library and place in an episode on every device they own.

42.1 What defines this archetype

An audio app makes one promise. Sound keeps playing, whatever else the phone is doing and wherever you go.

Each clause costs something.

• Keeps playing. A stall is the one failure every listener notices. So is a silence between two tracks that were recorded as one piece.
• Whatever else the phone is doing. The screen is locked, another app is in front, and the operating system is looking for processes to remove. The player has to stay alive with no UI.
• Wherever you go. The listener walks out of wireless range, rides through a tunnel, boards a flight, gets into a car, and picks up a tablet at home. Playback follows.

Four concerns dominate the design. Two more support them.

Concern	Why it dominates	Chapter
Playback	The buffer, the next item and the playback position are the product	Chapter 17
Background work	Almost all listening happens with the app off screen	Chapter 23
Downloads	Offline listening is a main feature, with rules attached to every file	Chapter 18
Platform surfaces	The lock screen, a watch and a car are where the app is used	Chapter 25
Offline and sync	The library, the play queue and positions are synced data	Chapter 12
Local storage	Recently played audio is cached, and downloads must not be evicted	Chapter 11

This chapter uses one term that the glossary does not hold yet. The play queue is the ordered list of items the player will play, together with the index of the current item.

The archetype has three variants. Many products combine two of them, and each feature then follows its own variant.

	On-demand music catalog	Podcast app on episode feeds	Live radio
Unit	A track of a few minutes	An episode of minutes to hours	A stream with no end
Who hosts the audio	The app’s own media delivery	Usually each show’s publisher	The station, or the app’s media delivery
What must be remembered	The play queue	A playback position per episode	Nothing, or a short window behind the live edge
Hardest playback problem	No silence between tracks	Continuing exactly where you stopped	Staying on through a weak network
Downloads	Protected, with a license and an expiry	Plain files, often fetched automatically	None

Section 42.6 gives the probe that separates each pair.

42.2 Requirements read from the product

These are requirements as a listener experiences them. None of them names a design.

What the app does

• Play an item within a moment of the tap, and keep playing when the screen locks or another app opens.
• Show the title, artwork and controls on the lock screen, and obey headset buttons.
• Move to the next item by itself. Albums recorded without breaks play without breaks.
• Let the listener build and reorder a play queue, and find it on another device.
• Move live playback from one device to another without starting the item again.
• Download items for offline use, and say when a download can no longer be played.
• Fetch new episodes of followed shows without being asked.
• Continue an episode from where the listener stopped, on any device.
• Appear on a watch and in a car, with the same library.

Qualities it must have

• No stall on an ordinary commute, including its dead spots.
• No silence at a track boundary that the recording does not contain.
• A pause for a call, and a pause when the headset disconnects.
• Hours of playback at a small battery cost.
• Modest use of mobile data, and none for downloaded items.
• Downloads that survive low storage, and a cache that does not grow without limit.

Of the seven constraints of Chapter 2, three bind hardest. Unreliable network shapes the buffer and the downloads. Process death shapes how the player saves its state. Platform rules decide whether the player may run at all when it is off screen, and what it must show while it does.

42.3 Running the probes

Run the general probes first, on one kind of content at a time. A product that offers both music and episodes needs two passes, because the two kinds usually take different designs. Chapter 4 describes how to run a probe cleanly.

Probes from Chapter 17

Chapter 17 holds the core probes. Run them with headphones in a quiet place.

Probe	Typical outcome for this archetype	What it tells you
P17.1 Weak start	Audio starts after a wait, with no audible change in quality	The delivery design stays Speculative. Audio hides it
P17.3 Airplane mode mid-playback	A music track plays to its end. A long episode plays for some minutes	The buffer target is the whole track, or minutes of an episode
P17.4 Lock the screen	Sound continues, with title and controls	Declared background audio with a full report to the system media controls
P17.6 Next item offline	The next track starts, and often plays to its end	The next item is fetched early. Section 42.4 explains why
P17.7 Position after a force-quit	Within a few seconds for an episode. The same track and queue for music	Position and queue are written to the local store while playing
P17.8 Continue on a second device	Exact after a pause, close after the force-quit	A synced playback position with a report interval
P17.9 Download then go offline	The download plays and seeks freely	A stored file with a license already on the device, or with no license at all

Probes from Chapters 23, 18 and 25

Probe	Typical outcome	What it tells you
P23.2 User-visible work	Playback continues with controls shown by the system	The player runs as user-visible work
P23.10 Days unopened	New episodes are present offline in a podcast app	A deferred task or a push wake refreshes and downloads
P18.8 Transfer conditions	A download waits for an unmetered network, or the app asks first	Conditions on the transfer queue
P18.9 Download pause and resume	Continues from where it stopped, also after a force-quit	A durable transfer queue with resumable downloads
P25.6 Sign out, then check every surface	Lock-screen controls and any widget clear	Surfaces read from one report and one shared storage area
P25.7 Watch with the phone off	Downloaded items play. Streaming works only on a watch with its own network	The level of the watch app

Probes from Chapters 12 and 11

Run the sync probes on the library, not on playback. Saving a track, following a show and editing a playlist are the mutations.

Probe	Typical outcome	What it tells you
P12.1 Offline read	The library and playlists appear, including ones not visited	The library is synced into the local store
P12.2 Offline write	Saving a track shows at once	Optimistic update with an outbox
P12.5 Two-device conflict, on one playlist	Both additions survive	A playlist is synced as a list of operations, not as one value
P11.4 Storage growth	The figure rises with listening, then levels off	A bounded disk cache of played audio
P11.5 Clear cache	The figure drops and downloads stay	Downloads and cache are stored apart

Audio probes

These seven probes are specific to the archetype. P42.1 examines the track boundary. P42.2 and P42.3 examine the play queue across devices. P42.4 and P42.5 examine downloads. P42.6 examines automatic downloads, and P42.7 the rule for conflicting positions.

New teardownOpen worksheet

P42.1 Track boundary

Do

1. Find an album whose tracks run into each other, such as a concert recording or a continuous mix.
2. Use a good connection and headphones. Turn off any crossfade setting in the app.
3. Play one track from its last 30 seconds and listen across the boundary into the next track.
4. Repeat at two more boundaries of the same album.

Watch

Whether the sound is continuous at the boundary, and whether any silence has the same length each time.

Read

No silence at any boundaryInferredThe player prepares the next item early and joins both tracks in one output, trimming the padding of each file.A short silence of about the same length at every boundaryInferredEach track is started as a new playback. The next item may be fetched early, but the two are not joined.A pause with a loading indicator at one or more boundariesInferredThe next item is not prepared before the current one ends. The boundary waits on the network.

Select what you saw to record it in your worksheet. Select it again to clear it.

P42.2 Queue on a second device

Do

1. Sign in to one account on two devices, A and B. Close the app on B.
2. On A, start an album, then add three unrelated tracks to the play queue and reorder them.
3. Leave A playing. Open the app on B and look for a now-playing bar and a queue screen.
4. Remove one queued track on B, if B allows it, and look at the queue on A.

Watch

Whether B shows what A is playing, whether B shows the same queue in the same order, and whether a change on B reaches A.

Read

B shows the same queue, and a change on B appears on AInferredThe play queue is one synced record per account, delivered to open devices over a persistent connection.B shows what A is playing, but not the queueInferredThe backend tracks the active device and its current item. The queue itself stays on the device that plays.B shows nothing about AInferredThe play queue belongs to each device. The backend may still receive position reports.

Select what you saw to record it in your worksheet. Select it again to clear it.

P42.3 Hand playback over

Do

1. Sign in on two devices, A and B. Play a long item on A and note the position.
2. On B, open the app and look for a control that lists your devices or offers to play here.
3. Choose B as the place to play. Note where the sound comes from and at what position.
4. If no such control exists, press play on the same item on B.

Watch

Which device makes sound afterwards, whether the item continued or started again, and how long the change took.

Read

A falls silent and B continues at the same positionInferredPlayback is transferred. B prepares the item at the shared position, then claims the role of active device, and A stops when it sees the claim.A keeps making the sound, and B only controls itInferredB is a remote control. Commands travel through the backend or the local network to the player on A.A stops and B starts the item from its beginningInferredThe backend enforces one active stream, but no shared position is handed over.Both devices play at once, each on its ownObservedThe devices do not know about each other. There is no active-device record.

Select what you saw to record it in your worksheet. Select it again to clear it.

P42.4 Offline queue meets a missing item

Do

1. Download two tracks or episodes, D1 and D2. Pick a third item, S, that you have never played and have not downloaded.
2. Build a play queue in the order D1, S, D2.
3. Turn on airplane mode, then start D1 near its end.
4. Listen until the player reaches S.

Watch

What the player does when the next item in the queue is not on the device.

Read

It skips S and plays D2ObservedThe player knows which items are on the device and prefers continuous sound over the order of the queue.It stops at S with a message or a loading indicatorObservedThe player keeps the order of the queue and waits for the network.It plays SInferredS was on the device after all. The next item was prepared while D1 played online, or it sat in the audio cache. Repeat with airplane mode on before you build the queue.

Select what you saw to record it in your worksheet. Select it again to clear it.

P42.5 Downloads after sign-out

Do

1. Download one small item and confirm that it plays in airplane mode.
2. Note the storage the app uses, from the device's settings.
3. Go online and sign out of the app. Note the storage figure again.
4. Sign in to the same account, turn on airplane mode, and look for the download.

Watch

Whether the storage figure drops at sign-out, and whether the item is still listed and still plays offline.

Caution. Signing out may delete every download in the app. Run this probe with one or two small downloads, on a connection where fetching them again costs nothing.

Read

Storage drops and the download is goneInferredDownloads belong to the session. This is the usual design for protected content, where each license is issued to an account on a device.The download is still there and plays offlineInferredThe file is not tied to the session. Typical of plain files such as podcast episodes.The download is listed but will not play until the device is onlineInferredThe file was kept and its license was not. The app must ask the license service again.

Select what you saw to record it in your worksheet. Select it again to clear it.

P42.6 New episode while unopened

Do

1. Follow a show that publishes every day at a known time, and turn on automatic downloads for it.
2. Close the app without a force-quit, some hours before the next episode is due.
3. Leave the device on power and on an unmetered network. Do not open the app.
4. An hour or more after the episode is published, turn on airplane mode, then open the app.
5. Repeat on another day with the device on battery and in low-power mode.

Watch

Whether the new episode is listed, whether it plays offline, and whether a notification announced it before you opened the app.

Read

The new episode is listed and plays offlineInferredA deferred task or a push wake found the episode and queued a transfer that completed with the app unopened.The new episode is listed but is not on the deviceInferredThe list was refreshed in the background. The transfer waits for the app, or for conditions that were not met.The new episode is not listed until the app is online and openSpeculativeNo background refresh ran. The app reads feeds or asks its backend only in the foreground, or the operating system withheld the run.

Select what you saw to record it in your worksheet. Select it again to clear it.

P42.7 Two positions for one episode

Do

1. Sign in on two devices, A and B. On A, play a long episode to about minute 30 and pause.
2. Open the episode on B and confirm that it offers to continue near minute 30.
3. On B, seek back to minute 10, play for one minute and pause. Wait a minute.
4. On A, force-quit the app, open it online and open the episode.

Watch

The position A offers. It held minute 30 and B last reported minute 11.

Read

A continues near minute 11InferredLWW by the time of the report. The latest act of listening replaces an earlier one, whatever its position.A continues near minute 30SpeculativeThe furthest position wins, or A prefers its own stored value over the backend's. The two cannot be told apart from this run alone.B never offered minute 30ObservedThe playback position is not synced between devices.

Select what you saw to record it in your worksheet. Select it again to clear it.

42.4 The design, concern by concern

Each subsection states the design this archetype usually takes and the reason. The components are those of the universal app model in Chapter 3.

The player as user-visible work

The player is client logic that belongs to the process, not to a screen. It starts when the listener taps play and outlives every screen of the app.

Of the four kinds of background execution in Chapter 23, only one fits. Playback is user-visible work. The app declares that it plays audio, the operating system keeps the process running while sound is really coming out, and the platform shows the activity through the system media controls. The grant ends when playback does. An app paused for an hour has no protection.

The player therefore treats process death as normal. It writes three things to the local store as it goes: the play queue, the index of the current item and the playback position. After a restart it rebuilds itself from them. P17.7 measures how often it writes.

The player also owes the operating system the four duties listed in Chapter 17: report what is playing, accept commands, yield the audio output to a call, and pause when the output disappears. In this archetype they are not optional polish. The lock screen, the headset, the watch and the car all reach the player through that one report and that one command channel.

Delivery and the buffer

Audio is small. A music track at a good quality level is a few megabytes, and a fast connection delivers it in seconds. Two consequences follow.

First, the delivery design is hard to see. Music is served either by progressive download or by adaptive streaming with a few quality levels, and the switch between levels is close to inaudible. Episodes are almost always one file at one quality, fetched by progressive download from the publisher’s host. Record what P17.1 shows, and mark the design Speculative unless the app has a quality setting that names the levels.

Second, the buffer target for music is the whole track. Once a track has started, the network can vanish and the track still finishes. That turns the weak point of the design into the boundary between tracks.

Played audio is usually kept in a bounded disk cache, so that a repeated track costs no data. P11.4 shows the bound. This cache is not a download. It can be evicted, and the app does not promise that anything in it will play offline.

No silence between tracks

A live album or a continuous mix has no pause between its tracks. Playing it correctly needs two things.

The next item is prepared early. As soon as the current track is fully buffered, the player prepares the next item in the play queue. It asks the playback service whether the listener may play it, fetches the manifest or the start of the file, fetches the key if the content is protected, and buffers the first segments. This is prefetching of the “next media” form in Chapter 11, with a prediction that is nearly always right.

The two tracks are joined in one output. Compressed audio carries a little padding at the start and the end of every file. The player has to trim it by the exact amounts the encoder recorded, decode the start of the next track ahead of time, and feed both into the same output without closing it.

function onBufferProgress(current, playQueue):
  next = playQueue.peekNext()
  if current.bufferedToEnd and next is not none and not next.prepared:
    prepare(next)          // entitlement, manifest or file start, key, first segments
  if current.remaining() < joinWindow and next.prepared:
    output.appendAfter(current.lastSample, next.firstSample)   // same output, padding trimmed

Three results are possible at a boundary, and P42.1 separates them. No silence means both parts are in place. A short silence of the same length at every boundary means the player starts each track as a new playback. A stall with a loading indicator means the next item was not prepared in time.

Early preparation has a cost on the backend. An item that was prepared and never heard must not count as a play. Plays are counted from reports of sound actually produced, not from requests for audio.

The play queue as synced state

In the simplest design the play queue lives in the player’s memory. A better one keeps it in the local store. The design typical of a music catalog goes one step further: the queue is one synced record per account.

type PlaybackState:
  queue: list of ItemId
  source                    // the album, playlist or station the queue came from
  index
  position, positionTakenAt
  playing
  activeDevice
  version

Three details of this record matter.

• Position is stored with the time it was taken. While playing is true, any device computes the current position from those two fields. A second device can draw a moving progress bar without receiving an update every second.
• One device is active. The record names the device that produces sound. The others show what it plays and can send commands to it.
• A version guards every change. Two devices that press play at the same moment both try to become the active device. The backend accepts the first change against a version and rejects the second.

Each signed-in device learns of changes over a persistent connection while its app is open, which is the real-time delivery of Chapter 14.

Handing playback from one device to another builds on this record.

function onTransferTo(thisDevice, state):          // runs on the target device
  item = state.queue[state.index]
  prepare(item, at: state.currentPosition())
  when firstAudioReady:
    accepted = backend.claimActive(thisDevice, state.version)
    if accepted: play()                            // the source stops when it sees the change

The target prepares first and claims second, so the gap in sound is short. The source stops when the record names another device. P42.3 shows the result: the same item, at the same position, within a second or two.

A podcast app usually stops short of this. Its queue is often per device, and what it syncs is the position per episode.

Downloads, licenses and expiry

A download is the whole-file design at the listener’s request. The mechanism is the download path of Chapter 18.

• A durable transfer queue. Each requested item is an entry with progress and conditions. A transfer worker drains it. A playlist of two hundred tracks is two hundred entries, a few of which run at once.
• Conditions. By default downloads wait for an unmetered network. P18.8 shows the condition and the wording the app uses for it.
• The permanent storage area. A download is placed where the operating system does not evict files under storage pressure. A download that vanishes when the device runs low on space was placed in the cache area by mistake.
• A synced list of what to download. Marking a playlist for offline use is a mutation. When the playlist gains a track on another device, this device downloads it.

In a music catalog every download is protected content. The file is encrypted, and it plays only with a license that the backend issued for this account on this device. Chapter 17 lists the visible consequences. Three of them shape this archetype.

• The license has an expiry. The app must come online at intervals, commonly every few weeks, to renew its licenses. The settings or help text often state the interval.
• The entitlement is checked at renewal. When a subscription ends, the next renewal fails and the downloads stop playing, although the files are still on the device.
• Downloads are counted per device. The backend keeps a registry of devices and enforces a limit. A screen that lists your devices with a control to remove one is that registry.

Sign-out usually removes downloads, because the licenses belong to the account. P42.5 tests this.

A podcast download is different in kind. The file is an ordinary audio file from the publisher’s host. There is no license, no expiry and no device limit. The app’s own rules decide how long it stays: delete after playing, keep the latest few per show, or keep everything. Those rules are eviction by product policy, and they are visible in settings.

Automatic downloads as deferred tasks

A listener who follows a show expects the new episode to be on the device before the morning commute. Nobody opens the app to ask for it. The work therefore runs with no user present, and platform rules decide when.

There are two parts: learning that a new episode exists, and fetching the file.

Learning. An episode feed is a document, published by the show’s maker, that lists the show’s episodes with the address of each audio file. Either the device or the backend reads it.

Design	How a new episode is found	Signature
The device reads feeds	A deferred task fetches each followed feed when the operating system allows	Works with no account. New episodes appear at irregular times, and late on a device that is rarely opened
The backend reads feeds	The backend fetches every feed on a schedule and sends a push hint to followers	Needs an account or a device registration. A notification arrives soon after publication, on every device at once

Fetching. A push wake or a deferred task lasts seconds to minutes, which is too short for a long episode on a slow connection. The usual design uses the short run only to add an entry to the transfer queue, and hands the transfer itself to the operating system. The file then arrives with no app process running.

function onNewEpisode(episode):                 // from a push wake or a deferred task
  if not settings.autoDownload(episode.show): return
  transferQueue.add(episode.audioAddress,
    conditions: [unmeteredNetwork, enoughStorage],
    owner: OperatingSystem)                     // continues after this short run ends
  applyRetentionRule(episode.show)              // for example, keep the latest three

Every condition in Chapter 23 that withholds background execution applies. Low-power mode, a force-quit on some platforms and an app that is rarely opened all delay the download. P42.6 measures the result, and its outcome varies with the state of the device.

Playback position per episode

For an episode, the playback position is user data. Chapter 17 gives the three levels: in memory, in the local store, and synced. This archetype takes the third.

The position is written to the local store every few seconds and reported to the backend at a longer interval and on every pause. Offline, the report waits in the outbox, where a newer report replaces an older one. This is a Level 2 write in the terms of Chapter 12.

Two devices can hold different positions for one episode. The rule that settles it is a design choice.

Rule	Reasoning	Weakness
LWW by the time of the report	The latest act of listening is what the listener means	A device that syncs late, with an old position and a fresh report time, moves the listener back
Furthest position wins	A late report never loses progress	Listening to an episode again from the start does not stick

P42.7 separates them. Beside the position sits a played flag, usually set at a threshold short of the end so that closing credits do not leave an episode unfinished.

One detail is particular to podcasts. Some publishers assemble the audio file at the moment of the request and insert different advertisements each time. Two devices then hold files of different length for the same episode, and one position in seconds points to different words. A position that lands a little off after a change of device, by a different amount each time, is consistent with this. The claim is Speculative.

Surfaces: lock screen, watch and car

Chapter 25 describes the surfaces. An audio app uses more of them than almost any other archetype, and nearly all are fed by two sources.

• The report to the system media controls. The lock screen, the notification area, a headset’s buttons and a connected car’s steering-wheel buttons all read the report and send commands back. The app draws none of them.
• A list of what can be played. A car surface and a voice assistant ask the app for content as data: sections, lists and items. The system draws approved templates. The useful observation is whether those lists load with no network, which shows whether they come from the local store or from the backend.

A watch app sits at one of the three levels of Chapter 25. As a remote control, it sends commands to the player on the phone. As a companion with a cache, it holds downloads that the phone transferred to it and plays them alone. As a client that works alone, it has its own session, streams over its own network and appears as one more device in the synced play queue. P25.7 separates the levels.

Tunnels and network switches

The design for a dead network is the buffer. Requests for audio are reads of immutable data, so they are safe to repeat. The player retries with backoff and continues from the byte or the segment it had reached. Chapter 13 covers the retry rules.

A network switch breaks the request in flight. The listener hears nothing, because the buffer covers the seconds it takes to retry on the new network. Run P13.5 during playback to confirm it. A stall at the moment of a switch means the buffer was thin or the retry was slow.

A tunnel that outlasts the buffer ends in a stall, unless the next items are on the device. An app with downloads has a choice at that point, which P42.4 exposes. It can skip to the next downloaded item and keep the sound going, or it can stop and wait. Skipping serves the promise of this archetype. Waiting serves the order of the queue.

Everything the player wanted to tell the backend during the outage waits in the outbox: position reports, plays to be counted and changes to the queue.

42.5 End-to-end architecture

Figure 42.1 shows the components that the probes imply for the most complete variant, a music catalog with downloads and a synced play queue.

Figure 42.1. The client and backend of a music catalog app with downloads and a synced play queue.

In the terms of the universal app model, the player and the transfer worker are background workers, the system media controls are platform services, and the playback and license services are services behind the gateway. A podcast app that reads feeds on the device has a smaller figure. The license service disappears, media delivery becomes a third party run by each publisher, and the backend may shrink to a position store or to nothing.

Figure 42.2 follows the flow that defines the archetype: the screen is locked, the listener enters a tunnel, and one track ends while another begins.

Figure 42.2. A track boundary crossed in a tunnel. The yellow phase needs nothing from the network.

42.6 Variants and how to tell them apart

Most of the variant is visible in the product itself. The probes settle the parts that are not. Chapter 5 describes how a signal becomes a claim with a confidence word.

Question	Discriminating probe	Reading
Protected catalog or plain files	P42.5, with P17.9	Downloads that vanish at sign-out, or that state an expiry, are held under a license
Play queue synced or per device	P42.2	The second device shows the queue, or only its own
Transfer or remote control	P42.3	The sound moves to the device in your hand, or stays where it was
Feeds read by the device or by the backend	P42.6, with P23.3	A prompt notification for a new episode on every device points to the backend
Position rule	P42.7	Latest report, or furthest position

Music catalog against podcast app. A music catalog owns its audio. It can encode several quality levels, protect every file and count every play. A podcast app plays files it does not host. It cannot change their quality, it cannot protect them, and it learns of new ones only by reading feeds. So the first has more backend and the second has more background work on the device.

Live radio. A station is a live stream. It is normally carried by segmented delivery, the design Chapter 19 describes for one-to-many streams, since a delay of many seconds harms nobody who is only listening. There is no play queue and no playback position. Two things are worth observing. Pause either stops the stream and rejoins at the live edge, or holds your place in a short window behind it. P19.10 separates the two. And the title of the current song arrives on its own channel. A title that changes several seconds before or after the music does shows that the text and the audio travel apart.

The honest limits. Audio hides more than video. The delivery design, the number of quality levels and the format cannot be seen from outside. The transport that carries a request through a network switch cannot be identified. Whether a file is protected is Inferred from expiry and sign-out behavior, and you should not go further than that. A probe observes the consequences of a protection and never tests the protection itself.

Signal	Design it points to	Confidence
Title and controls appear on the lock screen and headset buttons work	Player runs as user-visible work and reports to the system media controls	Inferred
A track finishes in airplane mode, and the next one starts	Whole-track buffer with the next item prepared early	Inferred
A concert album plays with no silence between tracks	Next item decoded ahead and joined in the same output with padding trimmed	Inferred
The app offers a crossfade setting	Two items are decoded at once so the next item is always prepared early	Inferred
A second device shows a moving progress bar for what the first is playing	Synced playback state that stores a position with the time it was taken	Inferred
Starting playback on a second device pauses the first	Backend record of one active device per account	Inferred
A control lists your other devices as places to play	Presence of devices over a persistent connection and commands pushed to the chosen device	Inferred
Settings say the app must go online every few weeks to keep downloads	Licenses with an expiry that are renewed against the entitlement	Inferred
Downloads stop playing after a subscription ends although storage use is unchanged	Protected files whose license was not renewed	Inferred
An account screen lists devices with a limit on how many may hold downloads	Backend registry of devices and their downloads	Inferred
A new episode is on the device in the morning without the app having been opened	Deferred task or push wake that hands a transfer to the operating system	Inferred
A notification for a new episode arrives on every device within minutes of publication	The backend reads episode feeds and sends a platform push to followers	Inferred
The app works with no account and new episodes appear at irregular times	The device reads episode feeds itself in deferred tasks	Inferred
The same episode has a different length on two devices and positions land slightly off	The publisher assembles the file per request. One of several possible causes	Speculative
Storage rises with listening and then levels off while downloads stay	Bounded audio cache kept apart from downloads	Inferred
The car screen shows the library and downloads with no network	Browse lists for the car surface come from the local store	Inferred
A watch plays downloaded items with the phone switched off	Watch app that is a companion with a cache or a client that works alone	Inferred
The song title on a live station changes seconds before or after the music	Title text and live audio travel on separate channels	Inferred

Search the signals from every chapter in the signal lookup.

42.7 What changes with scale

The client is nearly the same for a small audio app and a very large one. The player, the buffer, the transfer queue and the reports do not depend on the size of the audience.

The same at every size

• A player that runs as user-visible work and reports to the system media controls.
• The next item prepared early.
• Position and queue saved to the local store as playback proceeds.
• Downloads in a durable transfer queue with conditions.
• Reports that wait in an outbox while offline.

What changes

• Media delivery. A small app serves audio from one place. A large one serves it from edge caches near each listener, with popular tracks held close and rare ones fetched from further away. A start delay that is longer for an obscure track than for a popular one is a Speculative sign of this.
• Encoding. A small catalog holds one file per track. A large one holds several quality levels and formats per track, and chooses by device and by subscription tier.
• Live state. A synced play queue needs a persistent connection per open device and a small record per account that changes at every track boundary. At large size this is a service of its own.
• Counting plays. Payments to rights holders depend on play counts. Reports must be deduplicated and checked against abuse, because the client is untrusted.
• Reading feeds. A backend that reads feeds for a few thousand shows can fetch them all every few minutes. One that reads millions must rank them by how often they change, and a new episode of a small show appears later.

42.8 Completed worksheet

Chapter 6 describes the worksheet and the order in which to fill it in. The fields in this form are specific to audio. The probes of Section 42.3 fill most of them.

New teardownOpen worksheet

Stated license rules: expiry, online check and device limitSurfaces: lock screen, watch, car, widget, voice actionsBehavior on a call and on headset removalNotes and open questions

The fields that the Part II chapters add to the worksheet take these typical values for a music catalog app with downloads. A value that differs in your teardown is a finding. Record it with the probe that produced it.

Field	Typical value	Confidence
Delivery design, Chapter 17	Unknown from outside. Progressive download for episodes	Speculative
Buffer ahead	Whole item for a track. Minutes for an episode	Observed
Next item	Start of next item preloaded, often the whole item	Observed
Screen locked	Continues with system controls	Observed
Position across devices	Synced closely	Inferred
Long-running work in the background, Chapter 23	Continues with indicator	Observed
Refresh while unopened for days	Refreshed while unopened, in a podcast app	Inferred
Large transfer on cellular, Chapter 18	Waits for unmetered network	Observed
Watch app with the phone off, Chapter 25	Cached data only, or works alone	Observed
Offline level of the library, Chapter 12	2 Queued writes or 3 Local replica	Inferred
Backend components implied	Playback service, license service, queue and position store, async delivery, media delivery	Inferred

42.9 As an interview question

The question is usually asked as “design a music streaming app” or “design the client for a podcast player”. Interviewers like it because one screen hides background execution, storage and sync.

Clarify first. Four questions remove or add large parts of the design.

1. Music, episodes or live radio. Each has a different unit and a different thing to remember.
2. Whether offline downloads are in scope, and whether the content is protected.
3. One device or several, and whether playback moves between them.
4. Which surfaces count: lock screen only, or also a watch and a car.

Then state the promise from Section 42.1 and name the three places where it breaks: the track boundary, the tunnel and process death.

Go deep on three concerns.

• The player and its lifecycle. A process-level component that runs as user-visible work, reports to the system media controls and rebuilds itself from the local store. Draw Figure 42.2.
• Buffering and the next item. A whole-track buffer, early preparation of the next item, and what joining two tracks without silence requires. Say what early preparation does to play counts.
• Downloads. A durable transfer queue with conditions, storage that is not evicted, and a license with an expiry and a renewal. For episodes, automatic downloads as deferred tasks that hand the transfer to the operating system.

Trade-offs an interviewer expects to hear.

• A long buffer against data spent on audio nobody hears.
• A synced play queue against a queue per device: transfer between devices and a one-stream rule against a persistent connection and a new service.
• LWW against furthest position for an episode.
• Feeds read by the device against feeds read by the backend: no account and no backend against prompt notifications and one fetch per show instead of one per follower.
• A push hint against a deferred task for automatic downloads, and why neither can promise a time.

42.10 Summary

• An audio app promises that sound keeps playing, whatever else the phone is doing and wherever the listener goes. Playback, background work, downloads and platform surfaces dominate its design.
• The player belongs to the process and runs as user-visible work. It reports to the system media controls, which feed the lock screen, the headset, the watch and the car.
• A music track is buffered whole, so the weak point is the boundary. The next item is prepared early and joined to the current one in the same output.
• The play queue is a small synced record that names one active device. Handing playback over is a claim on that record after the target has prepared the item.
• Downloads run through a durable transfer queue with conditions. Protected downloads carry a license with an expiry, are counted per device and usually leave with the session.
• New episodes arrive through a deferred task or a push wake that hands the transfer to the operating system. The time of arrival cannot be promised.
• The playback position per episode is synced through the outbox. LWW and furthest position are the two rules, and P42.7 separates them.
• Three variants share the player and differ in the rest: a music catalog owns its audio, a podcast app plays files hosted by publishers, and live radio is a live stream with nothing to remember.