Designing for an uncertain future

Back in April 2016, I bought a BÖHM B2 60 Watt 40″ soundbar on sale for $71.39 plus tax, 40% off (otherwise stated: $47.60 off) the normal $118.99 price. I suspect it was a closeout promotion, because a writeup that appeared two months later had the BÖHM B2 further discounted (at a different retailer) to $55, versus a supposed original $200 MSRP. And the BÖHM B2 is seemingly no longer available for sale anywhere; the original Amazon listing has been nuked, and I can’t find an active website for the manufacturer, either:

The BÖHM B2’s sound was admittedly passable at best, but it served its primary purpose, to redirect and amplify audio coming out of a geriatric large-screen computer monitor in my office. Plus, in addition to the 1.8” (3.5mm) TRS analog audio input that I mostly leveraged, it also offered an array of other input options convenient for periodic product testing purposes:

Dual RCA analog
S/PDIF digital optical
S/PDIF digital coaxial, and
Bluetooth

To wit, I recently hooked up the soundbar to several streaming music receivers that I was evaluating. I realize that my elementary transducer choice was a bit odd, since the Audiolab 6000N Play and Bluesound NODE N130 are primarily targeted at audiophiles. However, my fundamental motivation with this project was to test device functionality versus the outer limits of delivered audio quality.

Initially, I connected both devices—one at a time, of course—to the soundbar’s dual-RCA analog input (thereby leveraging the devices’ built-in DACs), which worked fine. But when I then transitioned to tapping into either of the soundbar’s digital audio inputs (thereby instead leveraging the soundbar’s own DAC), I got nothing but silence from several music sources, Amazon Music and Tidal. In both service cases, I pay extra each month for “audiophile” quality source content, an upgrade which ended up being a critical detail.

Cutting to the chase, after a bit more experimentation I figured out what was going on. Not all the music I tried to play failed, only much of it, specifically the content that was encoded and delivered as “HD”, i.e., beyond Red Book Audio CD quality, with larger-than-16-bit per-channel sample sizes and/or higher-than-44.1 kHz and 48 kHz sample rates. Conversely, all the content I streamed from Pandora and Sirius XM played through the digital interconnect between receiver and soundbar just fine, as did “Red Book Audio”-only content from Amazon Music and Tidal.

Clearly, the soundbar’s integrated DAC didn’t know how to handle incoming HD audio bitstreams, even if “handle” simply meant “downsample”. Fundamentally, this situation was the result of the legacy S/PDIF interface’s unidirectional nature; there’s no support for an upfront “handshake” that would allow the transmitter and receiver to communicate their respective capabilities and negotiate a mutually compatible compromise transport format.

The soundbar’s remote control was starting to get flaky, anyway, and I couldn’t find a replacement anywhere. Plus, speaking of the remote control, its companion IR receiver was located on the far-right end of the soundbar, a not-conveniently-line-of-site placement in my office setup. So, the BÖHM B2 is currently sitting on my to-donate (with upfront disclosure) pile. I’ve replaced it with a more modern Hisense HS205, which I recently snagged on sale at Amazon for $34.99. Its IR receiver is centrally located, and it handles HD digital audio sources just fine:

Speaking of audio streaming, this time of a wireless nature, I’m reminded of the frustrations with my two Android-based smartphones, Google’s Pixel 4a (5G) and Microsoft’s Surface Duo, and my various Bluetooth headphone sets. When I listen to “Ultra HD” content sourced from Amazon, for example, it reliably streams just fine from both handsets to my Jabra Elite 75ts, Beats Studio Buds, Powerbeats Pros, and Google Pixel Buds Pros. What they all have in common is support for only the SBC and newer AAC codecs. Here’s an example screenshot, taken from the Android’s Developer Options of my Surface Duo’s Bluetooth Audio settings when connected to the Pixel Buds Pros:

My Sennheiser Momentum True Wireless 2 earbuds, however, are a different matter. Like my Sennheiser Momentum 2 Wireless headset, they also support the aptX codec, which delivers claimed higher quality albeit at the tradeoff of tangibly higher computational demands than those of its AAC and (especially) SBC siblings. Here’s what the Surface Duo’s settings look like with the smartphone connected to the Sennheiser Momentum True Wireless 2 earbuds:

Fortunately, unlike with the prior S/PDIF case study, Bluetooth does support an upfront handshake between an audio “source” and “sink” to, requoting what I previously wrote, “communicate their respective capabilities and negotiate a mutually compatible compromise transport format”. That’s why with most earbuds, my smartphones select AAC as the streaming codec, picking aptX only for the Sennheisers. But there seems to be no subsequent ongoing monitoring of the stream to assess audio quality (as measured by packet dropouts, etc.) and up- or down-throttle the settings (alter lossy compression quality to modulate the bitrate, as well as tweak the audio codec in use, the sample size and sampling rate, etc.) to compensate. To wit, both smartphones struggle when streaming Ultra HD content to the Sennheisers, the Surface Duo seemingly stuttering more in my subjective experience—a variance that also compels me to point the blame finger at the smartphones, not at their in-common earbuds.

To my earlier comment that aptX has “significantly higher computational demands than its AAC and (especially) SBC siblings,” this comparative result might not make sense at first glance, considering that the Surface Duo’s SoC is beefier than that of the Pixel 4a (5G). Both handsets also contain the same allocation of system RAM. That said, keep in mind, that the Surface Duo is (as its name reflects) a dual-screen device, capable of juggling multiple applications (including the Android home screen) at once, albeit with incremental demands on its processing and memory resources. Plus, although recent software enhancements have significantly reduced the Surface Duo’s bugginess, some amount of erratic behavior remains, along with overall seeming reduced software execution efficiency versus that of the Pixel 4a (5G). Therein lie, I suspect, the root causes of the audio dropouts I experience. I could even argue that Microsoft should have never offered aptX support on the Surface Duo at all…but I digress…

My last case study is also audio-themed, albeit this time not streaming-related. I still regularly use my geriatric iPod classic—which post-SSD upgrade has sufficient capacity to house the entirety of my voluminous music library—when listening to tunes both in my Volvo (where I rely on a cigarette lighter power adapter along with the vehicle’s sound system’s analog audio-input support) and my Jeep (via a third-party 30-pin adapter that directly taps into the factory sound system and handles not only audio transfer but also iPod remote control and charging).

(mine’s black in color)

For in-house charging and to-iPod music transfer purposes, on the other hand, I’m still clinging to a few legacy USB-to-30-pin cables:

Along with (the key focus of this piece) a few legacy Apple 5W power adapters:

Why the ongoing attachment to no-longer-sold, limited-current AC-to-USB chargers? Don’t I alternatively have plenty of higher wattage single- and multi-port chargers also lying around the home office? Yes, I do, in fact…but the iPod classic doesn’t work with the bulk of them. Its early, now overly-rigid charging-circuit—and/or software, I’m not sure which—implementation doesn’t seemingly handshake correctly with a higher-power source to negotiate 1A-max output current; instead, the iPod classic flat-out won’t charge at all, as a means of “protecting” itself.

Forecasting and designing for the future—accurately forecasting, to be precise—is difficult at best and often essentially impossible, especially if the standards you’re designing to aren’t similarly forward-looking. I get it. But as these examples hopefully get across, not doing so can doom the product into which you’ve poured significant development time and effort to a premature demise once it gets into customers’ hands. If you’re involved in developing industry standards, please strive to make them as flexible and forward-looking as possible. And if you’re developing hardware and/or software products based on those standards, please design them—within reasonable bill-of-materials and time costs, of course—as backwards-compatible supersets of those standards, again to maximize their usable life. Your customers—not to mention the otherwise consumption-crazed world at large—will thank you for keeping stuff out of the landfill. And longer term, your company will be rewarded with repeat-customer loyalty.

—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.

 Related Content

Streaming music reception: implementation differentiation
Obsolescence by design, defect, or corporate decree
Microsoft embraces obsolescence by design with Windows 11
Obsolescence by design hampers computer systems
Component obsolescence: Is your process up to the challenge?

<!–

–>

<!–

div-gpt-ad-inread

–>

The post Designing for an uncertain future appeared first on EDN.