How does the CD audio connector work?

Question

I am building a retro computer and found out that old CD drives have audio output connectors.

But how does it work? The computer can read all data from the CD using ATAPI/IDE. Why is there an additional audio output?

Answer 1

The audio outputs connect to a corresponding input on sound cards (or motherboards); see for example the “CD IN” connector at the top of this Sound Blaster Pro and the “CD_SPDIF” connector at the top of this Sound Blaster Live! (the latter uses a variant of S/PDIF for digital audio). The four pin analog connection was required for PCs labeled Multimedia PC Level 1 (this standard was published in 1991).

Audio data from CDs can be retrieved using ATAPI (strictly speaking, SCSI-3 multimedia commands), but doing so is CPU- and I/O-intensive and hard to do accurately. Most CD-ROM drives are capable of playing audio on their own, without help from the host computer; the host computer can therefore instruct them to play a CD (using the “PLAY CD” command), and leave them to take care of the playback. The audio is decoded in the drive itself, and output on the audio outputs (typically, the four-pin connector at the rear, and a headphone jack at the front). Even in single-tasking systems such as MS-DOS, you can start a CD using one of a number of tools, and continue using the computer as usual while the CD plays; similar tools are available on all platforms, e.g. cdtool on Unix-style systems.

Quite a few mid- to late-90s DOS and Windows games rely on this feature for background audio, sometimes even certain sound effects, and you’ll need to connect the audio output to your sound card in order to hear it. This allowed for high-quality audio with no CPU load. Examples include WarCraft II (although it has MIDI fallbacks for music), Quake, Grand Theft Auto… Other platforms used this too, e.g. PlayStation 1. Once typical systems were powerful enough to decompress audio in addition to handling the rest of a game, CD audio tracks became less popular — they occupy a lot of room on the CD, switching to compressed audio left more room for game content.

The Paranoia FAQ gives some hints as to the problems seen with ripping audio on early CD-ROM drives.

Some drives included hardware playback controls — minimally, play and stop/eject buttons and a volume control for the headphone jack, but some had buttons to skip backwards and forwards, and could be used with a remote control! If you provide power, you can use these drives without a PC at all. Going in the other direction, some modern optical drives no longer support audio playback at all; they don’t have any audio outputs and produce errors when audio playback commands are sent to them.

Answer 2

Just wanted to add a little color and clarity for those that weren't here in the late 80s / early 90s, or weren't (that) into computers:

There's a big distinction to make between a CD-ROM drive that is playing an audio CD (the way a standalone audio CD player does), and one that is reading the digital audio data from the disc and passing it along to the computer.

The latter (reading the audio data from the disc) is often called "ripping" -- as this is what you would do to import an audio CD into a music library application, like iTunes or Windows Media Player. The technical term for it is "Digital Audio Extraction," or DAE. The drive, in this case, is treating the disc much like a data disc -- just reading the bits and forwarding them to the computer, via the data bus interface.

This was not a given on early drives. Many of them treated audio CDs as different from data CDs, and weren't able to read audio sectors and return them as blobs of bytes. They were, of course, physically capable of it, there just may not have been a command in the drive's protocol to ask it to.

This became more commonplace with later drives, around the 4x or 8x era. It wasn't really a commodity function until the early 2000s, when MP3s and Sony's ATRAC spawned an industry of portable solid-state music players. Only then, was having a CD-ROM that could rip audio tracks a notable selling point for average users, where it was previously more of a niche feature for nerds (like yours truly) and/or people who owned one of those exotic and expensive "CD burners." :-)

After all, in 1995, what were you going to do with an audio file that consumed 10MB per minute of audio? Store it on your 420MB hard drive? A three-minute song would occupy around 7% of your entire disk!

Of course, the question was about real-time playback, so let's look at that in context of the time:

When CD-ROMs first made their debut in the computing market, they were often repurposed audio CD player transports with a fancy controller. The use-cases are similar, but not identical, particularly in that data applications tend to seek a whole lot more than audio CD players do, which may put more wear and tear on the optical pickup positioning mechanism than it was designed for. Audio CD players also don't need to be particularly fast.

Early data CD-ROM drives were indeed very slow. Poor throughput, awful seek times, etc. But, as manufacturers got savvy to this new market, things improved. However, since the actual difference between audio and data discs is really quite trivial, it didn't take much effort to retain the ability for these new data drives to continue behaving as a normal audio CD player in addition to their special purpose.

This functionality was, at first, just added because it could be -- here, you spent a couple thousand dollars on a new optical storage system, why not use it to play music when you're not accessing large online databases?

Once this became standard practice (as much as anything was standard in the early days), applications started to use this ability to add multimedia support. For context, this is when you might be looking up data like news articles, phone numbers, or medical references through a text-based DOS application; or perhaps on a 512x384 pixel, black and white Macintosh. In other words, playing sound and video files on the computer itself was either impossible, or barely possible. So, having the drive play snippets of CD-quality audio in-time with things happening on-screen was, as they say, "quite something."

A few years later, when EGA and VGA were standard on PCs, and some -- but not all -- of us even had dedicated sound cards, multimedia games used this trick as well, to add background music. (Or, in the case of certain LucasArts games for example, the entire soundscape -- dialog and all.) It was much higher quality than the synthesized FM sound of an OPL2 chip, or the single-tone beeps of a PC speaker. Even if you did have a sound card, the earlier ones were not CD-quality. You might have 8-bit sampling, instead of CD's 16-bit; or only mono sound instead of stereo; or 11-22kHz sampling rate instead of CD's 44.1kHz. Once cards like the Pro Audio Spectrum 16 and Sound Blaster 16 came out, it was technically possible (finally!) to play CD-quality digital audio, but it took a lot out of the CPUs of that time -- namely, 386s and 486s.

For these reasons, the CD-ROM drive itself was responsible for turning the digital data on the disc into analog audio. The computer couldn't, or would be entirely consumed doing so. Even later, in the Pentium era, the throughput of the ISA bus and, to an extent, the CPU-to-memory bus would be taxed with that chore. So, with the proliferation of Windows (especially Windows 95), you might fire up the Windows CD Player app to play some music while you worked on other things.

(Side note: This is the primary difference between the CD Player app -- which issues CD playback commands to the drive -- and later players like VLC, WMP, or iTunes -- which read audio data from the disc directly.)

This required very little from the computer -- basically nothing more than the occasional check-in with the drive to update the status (still playing?) and timecode for the track and time display. The drive did all the work. And that's why that audio jack exists.

Only later, beginning with the Pentium II and thereafter, was it really feasible to ask the drive to extract the audio data and have the computer play it back, as it would with a WAV file or similar. The computer had finally gotten fast enough that this wouldn't appreciably degrade your user experience in a multitasking OS -- as long as you had enough memory, at least.

This same process repeated with the advent of DVD. My Pentium II required a dedicated hardware MPEG2 decoder card, inserted in between the graphics card and my monitor, which would overlay the DVD video image over an empty window on the screen. It would also decode the AC3 audio track and deliver it to the sound card through an auxiliary analog header just like the Audio CD In jack on earlier cards. Late Pentium IIIs and Pentium 4s could decode DVD video in software, whereupon we again ditched the extraneous hardware and cables. Some video cards of that time did (and often still do for HD and UHD) support integrated hardware decoders to offload that CPU-intensive work. Computing tends to follow cycles like this, and every time we get general-purpose CPUs that are fast enough to take on today's media needs, we just up the ante on the resolution and complexity of the medium, generating a need for co-processors to assist again.

So, to sum up:

The data cable can carry audio data as bytes, for the computer to play. The audio jack can can carry analog audio to relieve the computer of the need to process the data itself. Which is used depends on whether the software asks the drive to play CD audio, or to read sectors from an audio disc.

Answer 3

Some more background:

Back when IDE (or pre-IDE, which also frequently had audio connectors) CDROM drives were introduced,

• Audio CD players were NOT a ridiculously cheap commodity that you can also get from an oversaturated secondhand market (as it was in 2022)
• Many computers you would fit these into would be unable to handle playing a digital audio stream from a CDROM for playback - due to one or more of
  • no PCM capable sound card installed or installable,
  • not running a multitasking OS that could deal with a constant I/O load with near-realtime requirements in the background
  • being plain underpowered - the minimum feasible machine to install a CDROM drive into would have been an 8086 machine with a 16bit ISA bus, DOS 5 and an mscdex-type driver (BT;DT 286 machine without a hard drive!).