Tutorials Developer

Koen Vos: The Speech Half of Opus

By Infinite Creation · Profile

At a Glance

Opus is the join of two codecs. The transform half came from Valin's CELT work. The speech half is SILK, developed at Skype by Koen Vos, and it is the reason Opus is good at the thing most of its traffic actually is: people talking. RFC 6716 names him as one of three authors.

  • Lived: active from the 2000s, Dutch
  • Anchor year: 2012, Opus published as RFC 6716
  • Strand: overlooked

Career

1

The problem as it stood

Voice over IP in the 2000s ran on codecs designed for telephone bandwidth, and the result sounded like a telephone. Skype needed something that held up over unpredictable internet connections and still sounded like a person in a room.

2

What he actually did

Vos developed SILK at Skype, a linear-prediction speech codec that adapts to available bandwidth and packet loss rather than assuming a fixed channel. Skype opened it, and it was then combined with CELT to form the hybrid that became Opus.

3

How it worked

Linear prediction models the vocal tract as a filter, so the encoder can send filter parameters and an excitation signal rather than the waveform. That is enormously cheaper than coding the audio directly, which is why speech codecs sound acceptable at bitrates where music would be unlistenable.

4

What it made possible

The speech half is why Opus works for conversation. A pure transform codec at conversational bitrates sounds thin, and a pure speech codec falls apart on music. Having both, and switching between them, is the design.

5

Where the credit landed

Vos is the third author on RFC 6716 and the least mentioned. His contribution is also the one most listeners actually hear, because most Opus traffic is speech rather than music.

Known For

  • Most Opus traffic is speech, so the SILK half is doing most of the work most of the time.
  • Skype opening SILK is what made the merge possible at all.
  • A codec that handles packet loss gracefully matters more on real networks than one with a better score in a lab.

Going Deeper

Most audio traffic on the internet is people talking, which makes the speech half the one doing the work.

The telephone assumption

Speech coding grew up assuming a fixed, narrow channel, because that is what the telephone network was. The internet is neither fixed nor narrow nor reliable. SILK was built for the second set of conditions, which is why it holds up on a bad connection where a codec designed for a clean channel falls apart.

Where This Fits

SILK became the speech half of Opus, a modern transmission link covered in A History of Broadcast Technology.

FAQ

Q: Why did Skype open SILK?
A: Opening it let it be combined with CELT and standardised as Opus, which made it universal rather than proprietary. That is a trade of control for reach.

Q: Does Opus still use SILK?
A: Yes. The linear-prediction layer in Opus is SILK, and in hybrid mode it operates alongside the transform layer rather than instead of it.

Vocabulary

SILK The linear-prediction speech codec developed at Skype and later opened, which became the speech-handling half of Opus. It was designed for unpredictable internet connections rather than for a fixed-bandwidth telephone channel.

Hybrid mode The Opus mode in which the linear-prediction and transform layers operate together, one handling the lower frequencies and the other the upper. It is what lets a single encoder cover speech and music without a format change.

Packet loss concealment Techniques for producing plausible audio when data does not arrive. On real networks this affects perceived quality more than raw coding efficiency does, because losses are common and audible.

Bitrate adaptation Changing how much data a codec produces in response to the connection available. A codec that cannot do this either wastes capacity or breaks up, and conversation is unforgiving of both.

Sources

Every record below was fetched and read before it was cited here. Checked 26 August 2026.

Translate this page

Machine translation provided by Google Translate, on Google’s servers. We do not check these translations and they will get technical terms wrong. The English page is the authoritative one. Following a link sends this page’s address to Google. Your browser may also offer to translate this page itself, which keeps the request on your device.