Hi there. I think it's because by the time SATA was around, Windows had learned to playback music CDs directly (by reading the audio tracks and streaming the PCM data to soundcard).

Previously, Windows merely told the CD-ROM drive to play back a certain audio track.
This also worked in DOS, OS/2 and other operating systems.

In Windows XP, there used to be an option somewhere in Control Panel to switch between analog/digital playback.

PS: "Digital" meant reading data over computer cable and output via soundcard, rather than SPDIF (a digital audio connection).

I have some late IDE drives that actually do have the header footprints populated from the factory but do NOT output a signal on them. The manual even says "not supported" or something. If you were to manually solder pins there, I suspect the result would be the same. These late drives simply do not have the built-in audio decoding anymore.

It is because later OSes are capable of converting the CD audio samples into data so it can be transferred from an IDE/SATA/USB cable. When the built-in audio decoder was used extensively on older CD driver, CPUs at the time weren't able to mix those samples in software without having any kind of performance hit.

maxtherabbit wrote on 2023-06-06, 14:39:

I have some late IDE drives that actually do have the header footprints populated from the factory but do NOT output a signal on them. The manual even says "not supported" or something. If you were to manually solder pins there, I suspect the result would be the same. These late drives simply do not have the built-in audio decoding anymore.

Can confirm, I have some nice IDE DVD-ROM drives that I bought ages ago because they looked to tick all the boxes BUT even though they have the analog output connector it goes nowhere on the PCB.
I was kinda hoping there would be some missing parts I could populate but nope. It's completely gone and the drive fw does not support analog output.

Just to add to everything said above: digital audio, i.e. through the bus and without the extra cable, was enabled by default since Win ME and was an option since Win 98. So there wasn't really a need for it quite early in the windows OS history.

Gmlb256 wrote on 2023-06-06, 15:40:

It is because later OSes are capable of converting the CD audio samples into data so it can be transferred from an IDE/SATA/USB cable. When the built-in audio decoder was used extensively on older CD driver, CPUs at the time weren't able to mix those samples in software without having any kind of performance hit.

The audio samples on the CD are still just data. It is converting that data sent over the cable back to audio via a D/A converter where previously the D/A converter was included in the drive itself.

cyclone3d wrote on 2023-06-06, 17:15:

The audio samples on the CD are still just data. It is converting that data sent over the cable back to audio via a D/A converter where previously the D/A converter was included in the drive itself.

OS reads the audio data as RAW data packets via specific ATAPI/SCSI commands (it can't be done using the older IDE/CDDA commands, which only allow you the play/pause/stop/eject/change track commands), and then the OS process them via software stack. In windows this is done via Kernel Streaming (ks.sys) module which turns them to (Sysaudio.sys) for mixing with other audio sources. Modern Windowses even do this purely in user mode. You can also dump the RAW data from Kernel Streaming (how old mp3 encoders used to do), or bypass it entirely and get the RAW PCM data from the SCSI stack (yes, ATAPI uses the SCSI path).

Back in the day this would impose certain load in the CPU, specially if your IDE/ATA controller didn't had support for DMA. Processing the audio and mixing it with other OS sound sources would impose its load too, specially when the alternative old method was a direct audio connection from the CD to the sound card chip pins, and the mixing was done in the chip itself via hardware.