[SOLVED] Windows: Sound becomes distorted after 1 second of playback

So today I started encountering a very weird audio issue: When I play music, it sounds normal in the beginning, but then after about a second the sound gets distorted, as if it is muffled, or as if it is undergoing severe lossy compression.  If I stop and resume the music, it goes through the same.

Normally I would know what to do in this situation, but as the years pass Microsoft keeps changing Windows, in the direction of making them dumber and dumber, so in Windows 10 I cannot find the old sound options dialog that I used to use to fix this problem.

Looking around the interwebz for a solution was not easy, so I decided to document the solution that I found.  If you are a power user, you can skim through the text and only look at the words in bold-italics.

1. Type Win+R and type mmsys.cpl. This will bring up the good old sound options, which Microsoft recently made inaccessible by any means other than this magical incantation, because obviously, nobody should ever want to fix any sound problems, because obviously, Windows has no sound problems.
2. In the Playback tab, locate your Speakers. If you are playing music at that moment, they are easy to locate from the live volume meter right next to them. 
3. Select Properties on your speakers.  (Not Configure, but Properties.)  This should open a Speakers Properties dialog.
4. On the Speaker Properties dialog, select the Advanced tab.
5. Near the bottom of the Advanced tab there is an Enable Fucked Up Sound checkbox, which is actually labelled Enable Enhancements.  (Euphemism has always been Microsoft's forte.)
6. Uncheck that checkbox; you are done.

Afterword

I probably started experiencing this problem right after pairing a new bluetooth sound device. Apparently when Windows detects a new sound device it sets some things up for it, and while doing that it entirely arbitrarily also goes and resets some settings for existing devices, e.g. it enables this "Enhancements" setting for my existing speakers.

A few good reads from Simplethread

I found them at a place called Simplethread while randomly browsing. 

I thought I'd post links here for posterity.

Taming Names in Software Development by Joseph Glass (2022)
https://www.simplethread.com/taming-names-in-software-development

Agile at 20: The Failed Rebellion by Al Tenhundfeld (2021)
https://www.simplethread.com/agile-at-20-the-failed-rebellion

20 Things I’ve Learned in my 20 Years as a Software Engineer by Justin Etheredge (2021)
https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer

Debating with other Software Engineers

Stackoverflow and the whole Stackexchange network is good for asking very narrowly-scoped questions that can receive objective and preferably authoritative answers that cite documentation or definitions. Any kind of question which is subject of opinion, or liable to elicit debate, is off-topic there. This means that stackoverflow is only good for asking strictly technical questions, and there is an upper limit on how valuable this can be. Sure it can be very helpful when you are trying to solve a specific technical problem, but in the grand scheme of things, it is irrelevant; from a philosophical point of view, it is trivial.

I have been looking for ways to discuss with other software engineers (preferably experts) issues that are related to software engineering but are in fact very much subject of opinion. These are the interesting questions. I do of course already have my own opinions, which tend to either deviate or be diametrically opposite from the prevailing industry trends, so it would be very useful to me to debate these issues with others to see what they have to say. Clearly, either I am wrong, or the entire industry is wrong; wouldn't it be nice if we could debate this and have it settled?

To this effect, I decided to give a few forums a try, to see if it is possible to have debates in any of them. As it turns out, there seem to be very few options available, and things are rather quiet in each one of them; most people seem to be doing nothing but consuming content generated by influencers instead of participating in discussions. In this post I am listing my findings so far. I will be amending it as I gather more information.

Definition: Collaborator

I have been coming across the term collaborator in software literature, and I have been using it too in my own writings, but without having seen it defined. I tried searching for its definition, but could not find any. In UML the term collaboration is vaguely described, but not the term collaborator. After asking on Software Engineering Stack Exchange I was pointed to what is in almost all certainty the original definition, but it turns out that it is very old, and slightly problematic, so I thought I should provide a modern definition here, at the very least for use in my own writings.

Here it goes:

A collaborator is a component invoked by another component to do a job.

(And since the context is software, these are, of course, software components.)

Origin of the term

If you are using mock objects you are doing it wrong.

Abstract:

The practice of using Mock Objects in automated software testing is examined from a critical point of view and found to be highly problematic. Opinions of some well known industry speakers are cited. The supposed benefits of Mock Objects are shown to be either no real benefits, or achievable via alternative means.

Collaboration Monitoring

Abstract:

An automated software testing technique is presented which solves the fragile test problem of white-box testing by allowing us to ensure that the component-under-test interacts with its collaborators according to our expectations without having to stipulate our expectations as test code, without having the tests fail each time our expectations change, and without having to go fixing test code each time this happens.

On Test-Driven Development (TDD)

Let me get one thing out of the way first: I am open to Test-Driven Development (TDD). I am not currently practicing it, because when I gave it a try some time ago it did not seem to work for me, but I do not have any objections to it in principle, so I might give it another try in the future. Let us just say that it was not love at first sight, but then again some relationships do take some time to warm up.

Having said that, let me now express a few reasons why I am skeptical of TDD. The previous paragraph should have established that I am not trashing TDD, I am just expressing some reservations.

So the "master" branch is not kosher anymore

The origins of the debate go so far back that they are lost in the mists of time, but a good starting point (which contains references to prior debate) is an Internet Draft from 2018 titled Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs. Some especially woke communities like the Python community had already started applying some of the recommendations in this draft as early as 2019, but things really picked up steam in 2020, with the murder of George Floyd.

On messages and message-passing

Over the decades, numerous software system architectures have emerged which require invocations across subsystems to be done via message-passing instead of programmatic interface method calls. Such architectures are so common that many programmers have come to regard message-passing as an end in and of itself, oblivious of the fact that it is nothing but a (poor) technical mechanism for accomplishing a certain architectural goal.

Intertwine

Abstract

A mechanism is described for automatically converting method invocations of any programmatic interface into a single-method normal form and converting back to invocations of the original interface, so that general-purpose operations can be performed on the normal form without explicit knowledge of the interface being invoked. Implementations are provided for C# and for Java.