Higher-priority alarms should interrupt lower-priority playback

What it is

Preemption lets a higher-priority alarm end lower-priority playback instead of waiting for it to finish. It turns priority from a sorting label into a rule with teeth: if a high-priority event cannot jump the line when needed, its priority is only a name.

Why it happens

Waiting for playback to finish adds its full duration to a critical event's delay, and the cost of delay rises with severity. Preemption works because the value of auditory information decays in time: a warning loses value until it is heard, while interrupted lower-priority content can usually be replayed or moved to the screen. Preemption has costs too, since it breaks content integrity, so it needs a companion rule about where interrupted content goes.

Studying it

Trigger a high-priority alarm midway through lower-priority content and measure detection latency, whether users correctly switch to the new event, and whether the interrupted content is later recovered. Measures include preemption latency, error rate, and perceived confusion. Control the remaining length of the interrupted content, since preempting near its end yields little but still pays the interruption cost.

Where it stops holding

Content that must not be interrupted forms the boundary: legal notices, safety instructions, or playback the user explicitly requested can cause real loss if cut off. There, pausing and resuming at a suitable moment is the workable move rather than preemption. If preemption happens often, users come to expect that nothing finishes, which erodes trust in all system output.

Applying it

• Define which content is preemptable and protect user-initiated playback and anything needing full acknowledgement by default.
• Start the higher-priority alarm immediately on preemption, with no transitional tone that adds further delay.
• Record the interrupted content and offer a recovery point later, so the user knows something remains unfinished.
• Verification: fire a high-priority alarm mid-playback and measure how long until it begins sounding, then confirm the interrupted content reappears somewhere recoverable.

Related

• Within the group: D2.10.1 Simultaneous alarms need arbitrated ordering, not overlapping playback · D2.10.3 Arbitration must tell the user that more alarms are queued
• Adjacent: D2.06.3 Speech output must support interruption and replay · D5.06.5 Interruptive versus queued arbitration
• Search terms: alarm preemption · priority override · interruption cost