True but it's not like devs even bother with it on PC after so many years .
This coming from a gen where the 2 main consoles had 6 cores and it 8 years later .
That's because avoiding deadlock and dealing with race conditions is a bitch, and it's not easy to design an interactive product such that the threads are mutually exclusive. Every time you have one thread do something that could impact another, you have to make sure to implement safeguards in your code to avoid potential race conditions.
IE: You want to isolate sound to one thread. A user input can trigger a sound (jumping, firing a gun). So can a game engine event (a building collapsing, an enemy moving, etc).
You need to make sure that when one thread is writing to the sound thread, the other isn't. And you need to make sure that when one thread is no longer writing to the sound, it frees up the process to be accessed by another thread.
In a single threaded system? Well, an action triggers a sound and it happens. Whatever code is being executed at any point in time is all that exists, and all that matters. You don't have to worry about some weird race condition between threads triggering a catastrophic failure.
So the solution might be to have sound as part of the main thread, and only have other threads deal with processes that have no sound associated with them. Like rendering visuals, or doing physics calculations.
But what if the rendering has to be synched up with the sound in the main thread? Or the value of the physics calculation is a collision detection between two objects, and that produces a distinct sound?
What if the physics don't match up with what's being rendered?
Etc.
Every possibility, including those that shouldn't be possible, has to be accounted for.