End-of-year tech-hiccups redux

Last time, in introducing this blog post series, I mentioned that as the year was drawing to a close, I seemed to be dealing with an ever-increasing number of tech hiccups, big and small alike. I focused specifically on two classes of issues:

Those involving (among other things) new-to-me technologies and products associated with them, such as high-end video capture equipment, and
Those involving computers, both ones for which I’d been compelled to make significant operating system and applications updates due to existing-software support cessation and those that I’d needed to outright replace, driven by obsolescence by design.

In that previous writeup, I dove into three case studies associated with the first bullet point. This time, the second bullet point gets the three-example treatment. Without further ado…

An SSD with one quarter of its claimed capacity

As I mentioned last month, my in-progress transitions to Thunderbolt 3- and 4-based computers have also motivated me to explore flash memory-based external storage—specifically DAS, or direct-attached storage—products. I specifically referenced, for example, one of the two OWC Mercury Pro U.2 Dual enclosures I’d purchased, which I then populated with a Shuttle U.2 carrier containing two 2TB Western Digital BLACK SN750 SSDs. The latter are the focus here.

Reiterating what I previously mentioned, while I rarely buy used SSDs, the prices I got for these were irresistible. Amazon had run a 15%-off sale on some of the inventory in the Warehouse area of its website during the company’s mid-October Prime Big Deal Days promotion period. Among that inventory were two 2 TB BLACK SN750s, priced and described as follows:

$93.25 ($79.26 after discount)
Used – Acceptable
Cosmetic imperfection(s) bigger than 1″ on bottom or back of item. Item will come repackaged.
$108.60 ($92.31 after discount)
Used – Good

The BLACK SN750 is “only” a PCIe 3.0 SSD, versus a newer and speedier PCIe 4.0- or PCIe 5.0-based alternative. But given this particular usage pattern (externally tethered to a computer over an intermediary TB3 interface) I suspected it’d swamp the external bus regardless. And considering that this same SSD is, as I type these words, selling brand new for nearly $300 at retailers such as Amazon and Newegg (although curiously, I just noticed that it’s only $109 at WD’s own online store right now), I think you’ll understand why I was willing to roll the dice on these two. My openness was fundamentally driven by the fact that I was planning on running the two-drive array in redundant mirrored RAID 1 mode anyway, and was especially the case in this particular circumstance since that from past experience, I was confident I’d have no trouble returning one or both for full refund if any within-30-days problems arose.

What problems? Well, past writeups of mine had highlighted SD cards whose actual capacities didn’t match their claims, along with those whose interfaces weren’t as speedy as promised.

But I’d (naively, it turned out) presumed that it’d be harder to fake out the performance or other attributes of a SSD, specifically one in a “naked” M.2 form factor (vs an enclosure-based 2.5” alternative). Instead, I’d assumed the worst that might arise would be a drive already heavily used and full of “bad blocks”, diminishing its remaining usable capacity along with shrinking the timeframe until inevitable full failure. How’s that saying go…“ignorance is bliss”?

Here’s what the “Used – Good” drive looks like:

It passed all of my testing (including a full reformat to exFAT) with flying colors.

Now here’s the “Used – Acceptable” one.

Cosmetically, and contrary to Amazon’s description of it, it looked fine to me, although it had definitely arrived repackaged…it showed up solely inside a taped-up antistatic bag. The first hint of trouble came when it seemingly reformatted much faster than its sibling. The second hint of trouble came when I looked at its reformatted capacity:

500 GB? What? But the official-looking backside label says it’s a 2 TB drive? All became clear when I fired up my copy of CrystalDiskInfo for a more thorough examination:

It was a 500 GB drive. And it wasn’t a WD BLACK WD750. What you’re actually looking at is an entry-level WD Blue SN550 SSD, a heavily used one at that, judging from the accumulated read and write cycles and power-on hours along with CrystalDiskInfo’s overall health rating for it.

But I was right about one thing; the backside label claiming a 2 TB capacity was official. How is it possible to reconcile these seemingly contradictory data points? Recall first that these particular BLACK SN750 variants came with heat sinks surrounding the M.2 module PCBs. Next, watch this video and the following video (I don’t speak the native language in either case, but I don’t think you need to understand the narration to get the point):

Now I’ll show you the side views of this particular SSD:

While not obvious unless you already know what you’re looking for, there’s a bit of wear on the heads suggestive that the screws had likely been removed and later reinstalled. Ironically, had the previous owner spent a few seconds on them with a black Sharpie, he or she could have completely covered the crime’s tracks. Because, as far as I’m concerned, a crime against Amazon is exactly what was committed, unfortunately the latest in a series of initial-customers’ scams against the company whose outcomes have also impacted me.

What presumably happened here is that the previous owner bought a brand new 2 TB Western Digital BLACK SN750 SSD from Amazon, swapped out the M.2 module PCB in it for his or her existing and heavily used, inferior-performance 500 GB WD Blue SN550 SD, and sent it back for full refund. Shame on them. I only hope that Amazon follows my submitted diagnostics-results advice and “eats” the loss instead of trying to resell the SSD again.

The overenthusiastic character viewer

In case it wasn’t already obvious from the abundance of vs-x86 claims that Apple made at its late-October surprise launch event, the company is highly motivated to move its remaining user base of legacy Intel-based Macs (folks like me) to successor Apple Silicon-based computers. Some of this encouragement comes, as we saw on October 30, from oodles of performance- and power consumption-themed comparisons. Some of it comes from intentional, documented operating system feature set omissions with Intel-based hardware in comparison to that same software running on Apple Silicon platforms, beginning with MacOS 12 “Monterey”. And some of it, largely undocumented (at least from Apple itself) and (presumably, although maybe I’m just being charitable) unintentional, comes from bugs that seemingly crop up solely in x86-based Macs. This as well as the final section of this post showcase two maddening examples.

As mentioned before, I strive whenever possible to run the oldest version of MacOS still actively supported by Apple, consciously trading off latest-and-greatest features for peak probability of software stability. To wit, back in September I out of-necessity migrated my actively-used computer stable (one last time, alas) from MacOS 11 “Big Sur” to “Monterey”, commensurate with MacOS 14 “Sonoma’s” gold release and the consequent cessation of “Big Sur” support (Apple traditionally supports both the current and prior two major O/S versions concurrently).

Immediately afterwards, I started noticing that whenever I’d press the Fn (function) key in the lower left corner of the keyboard, to raise or lower the system volume, for example:

the Character Viewer utility built into MacOS would also pop up:

(quick aside: you can learn a lot about a person by seeing what emoji they commonly use, eh?)

This behavior was new to MacOS Monterey, and it frankly drove me batty. What I ended up discovering, after no shortage of research and intermediary dead-ends, was that MacOS Monterey added a keyboard setting that, by default, brings up Character Viewer each time you press the “Globe” () key, multiplexed with Fn on the keyboards that come with newer Apple computers based on Apple Silicon SoCs. Here’s an example of what I’m talking about, from the M1-based 24” iMac’s discrete keyboard; the same goes for laptops with integrated keyboards:

And here’s a default MacOS Monterey setting screenshot taken straight from my computer:

The likely obvious problem with this, if you go back and look at the photo of my keyboard, is that it has no Fn-multiplexed “Globe” key. Apple’s software either wasn’t smart enough to differentiate between legacy and newer keyboards or was intentionally focused solely on Apple Silicon Macs, ignoring the legacy installed base of x86 computers and keyboards in the process.

Once I overrode the defaults:

Sanity was (arguably…I know…) restored.

Tangled up in Blue(tooth)

In unfortunate contrast to the prior Monterey-migration-related issue, this one hasn’t yet been successfully resolved and my necessary workarounds for it are fundamentally flawed. Shortly after logging into my first Zoom meeting post-Monterey upgrade, as-usual using my pair of AirPods Pro earbuds for both audio output and input (i.e., microphone) functions, I noticed that the sounds streaming into my ears first became choppy then dropped completely. Others in the meeting reported to me over Zoom Chat that the same thing had happened to the audio that I was outputting, and they were listening to. Out of necessity, I switched to the laptop’s inherently inferior built-in speakers and microphone array for the remainder of that meeting, then immediately jumped on Google to see whether this was a just-me or more widespread issue.

What I learned was deeply disturbing. Apple had apparently revamped the Bluetooth audio software subsystem beginning with Monterey, a decision which resulted in (at least) two significant issues, the second one of which remains seemingly unresolved to this day even through two successive major operating system revisions…and primarily to completely afflicts x86-based systems.

The first bug existed in Monterey betas and, despite beta tester feedback, remained present in the “gold” release. And it lingered through incremental updates for more than six months and for all systems until finally fixed. That this was the case despite its combination of seemingly obvious presence and functional importance is mind-blowing; thankfully I hadn’t come across it myself, as I’d jumped straight to the latest Monterey release when upgrading. In summary: whenever the user of a Bluetooth headset or earbuds set (Apple-branded or otherwise) muted the mic input, the output audio would also mute; the two settings were inexorably linked. The workaround employed by some app developers ignored the user-desired Bluetooth audio input device setting and instead “hard-wired” the integrated microphone array. Hold that thought.

In the process of (unsuccessfully, to date) debugging my Bluetooth audio issue, I learned something interesting…one of those obvious-in-retrospect things, to be exact. At one point, I’d been streaming a YouTube-sourced music concert in the background while messing around with both system-wide and Zoom-specific audio settings. Any time I selected the earbuds’ mic as my audio source, the tunes I was hearing over the earbuds’ speakers switched from stereo to (after a short delay) mono, “tinny” mono at that.

It turns out that the Bluetooth specifications don’t support simultaneously using one profile for transmitting audio to a Bluetooth peripheral and another profile for audio transmitted from that same peripheral. The profiles need to be the same in simultaneous-use scenarios, as well as being the mic-friendly lowest common denominator, specifically HSP (the handset profile) or HFP (hands- free profile). This means that whenever you select a Bluetooth device’s mic as the application’s audio input source, the playback profile switches away from A2DP (and whatever high-quality codec it had been using) to voice-tailored CVSD or an equivalent low-quality codec, too. And to clarify, this profile-switching behavior is generic, not O/S-specific.

I tried everything I could think of to minimize if not completely eliminate the misbehaving audio behavior I was struggling with. I boosted the CPU priority of the Bluetooth and Zoom processes (again to clarify, this issue affects every application that potentially uses a bidirectional-stream Bluetooth audio device, but we mostly use Zoom at my “day job”); no tangible improvement. Someone in one of the online discussion threads I perused in my research had suggested that disabling the Airplay Receiver service newly added to Monterey fixed the issue for them. This setting was originally “exposed” in Monterey to Intel-based Macs but was later removed, for unknown reasons, but I found a way to control it via the command line; again, though, no improvement. And someone else had said that Apple tech support ultimately told them that they needed to disable 2.4 GHz Wi-Fi on their LAN and run it 5 GHz-only. Sorry, not for me.

Ultimately, on a hunch I tried the workaround that the folks at Octopus Think had implemented as a temporary “patch” for the now-fixed other (linked mute settings) Monterey Bluetooth audio issue. Specifically, I tried instead using my laptop’s built-in microphone for audio input in Zoom, while still using my AirPods Pro headset for audio output. Huzzah; no more glitches! The issue seems to be specific to the HSP and/or HFP profiles (Apple has unfortunately deprecated support for its Bluetooth Explorer utility, so I can’t tell which profile, or for that matter which codec, is in use at any point in time, aside from the already-noted generalities), or, said another way, simultaneous use of the same Bluetooth device for both audio input and output purposes.

Generally, speaking any time I use a microphone found on a device different from my Bluetooth headset but still somehow connected (wired or wireless) to my computer, everything’s fine. I only run into problems when I use both a given Bluetooth headset’s or earbuds set’s mic and its speakers. Thankfully the mic array built into my MacBook Pro is reasonably directional in its pickup pattern, so background noise is inaudible on the other end of the connection as long as it’s not too egregious. That said, nothing beats a microphone only a couple of inches away from your mouth, so I remain springs-eternal hopeful that this bug too will eventually get squashed.

Over to you

I trust that I’m not the only one who’s encountered baffling system hardware and/or software glitches. And I also trust that I’m not the only one who’s (sadistically, admittedly) enjoyed, even if only a little bit, successfully debugging them to root cause, despite the migraines and teeth-gnashing they also cause. Please share your own tech-hiccup tales in the comments; your fellow readers and I will enjoy reading them! And have a happy holiday season, everyone, along with wishes for an even better 2024.

—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

VIDEO AD

–><!–

div-gpt-ad-inread

–>

<!–
googletag.cmd.push(function() { googletag.display(‘div-gpt-ad-native’); });
–>

The post End-of-year tech-hiccups redux appeared first on EDN.

Become a member

Become a member

Become a subscriber

Become a sponsor