Azra

Almost always configuration, and the reason is a piece of hardware behaviour people do not know about: one physical jack is often several possible outputs, and something has to choose.

Modern audio chips have a small number of internal converters wired to a switching matrix. The jack can be a headphone output, a line output, or on many machines a microphone input, and the driver picks based on what it thinks was plugged in. That guess is what fails.

So the diagnostic order is:

1. Look at the output device list while the headphones are plugged in. If a new device appears, the machine detected the plug and the routing is wrong, not the hardware. If nothing appears, detection failed — which is still usually configuration.
2. Check the jack's assigned role. Most sound systems expose the connector's function as a setting. If the jack is set to line-out or microphone, headphones will be silent and nothing will look broken.
3. Check for a second volume control. Many chips have independent controls per output, and the headphone one is frequently muted separately from the main one. This is the single most common cause and the most invisible.

Practical note on the wiring, since you have checked it three times: check it against the module's own silkscreen, not against the tutorial's diagram.

Modules with the same chip are sold with different pin orders by different manufacturers, and the picture in a tutorial is of the author's version. Reading the labels on your actual board catches this instantly, and it is a common cause of a correct-looking wiring that is wrong.

That second volume control deserves its own paragraph because of how often it is the answer.

On Linux, alsamixer shows every control the chip exposes, including ones the desktop mixer hides. Press F6 to pick the card, then look for anything named for headphones, front, or automatic mute — and check for MM under a control, which means muted. Unmute with m.

There is often a control called something like "Auto-Mute Mode", which silences the speakers when headphones are inserted. If that is misconfigured you can get the reverse of your problem, and toggling it sometimes fixes the detection entirely.

On Windows the equivalent is checking the playback devices list with "show disabled devices" turned on, since a disabled output looks exactly like an absent one.

Between those two, the great majority of these are solved without touching a driver.

Two behaviours that confuse people the first time, and are not faults.

Opening the port resets the board on many designs. The control line the terminal asserts is wired to reset. So connecting restarts your program — which is convenient for seeing boot messages and surprising if you expected to attach to something already running. Some terminals let you disable that.

Closing the terminal can leave the board in an odd state, and unplugging while a program has the port open sometimes requires a replug before it is usable again.

On Linux there is also a permissions layer: your user needs to be in the group that owns the serial devices, otherwise the port exists and cannot be opened. Adding yourself and logging out and back in is the fix, and the error message rarely says so.