Tag Archives: engineering

Asheville, Walnut Cove, Biltmore Forrest and Western North Carolina’s Audio and Home Theater specialists present Cane Creek AV and Paul McGowan – PS Audio, Intl.

Making the most of it

Engineers work with compromise because there are no design projects without limitations. Even the most exotic projects run up against the laws of physics from time to time.

Which is why we often confuse the word compromise with failure. It is not a failing to compromise, it’s what we all do to make things work.

In fact, we can safely suggest that engineering is the art of compromise. If we’re engineering a bridge we have to set limits. One view of those limitations sounds like a failure: the bridge can’t support the weight of an army tank. But, it wasn’t designed to. A more relevant view is to ask whether or not it meets or exceeds spec.

Exceeding our goals doesn’t sound like compromise, and it certainly doesn’t sound like failure. In fact, we’ve made the most out of what we have to work with.

When you’re judging a piece of audio gear it’s perhaps more important to evaluate it on how closely it meets expectations rather than ticking off a list of what it lacks.

No product has everything. The question should be, does it have what you want?


Asheville, Walnut Cove, Biltmore Forrest and Western North Carolina’s Audio and Home Theater specialists present Cane Creek AV and Paul McGowan – PS Audio, Intl.

Unexpected pleasures

When engineering handed me the fruits of their 10-month journey to build the Stellar Strata amplifier I was somewhat underwhelmed. It just worked. No bells, no whistles, no fireworks. It just flawlessly worked.

A team of three full-time programmers had been laboring for nearly a year to make the control system for Stellar Strata unnoticeable. They succeeded, then they celebrated their boring achievement.

Perhaps a little explanation is in order.

Most of our products have user interfaces. These are controlled by microprocessors and a lot of programming. Over the years, the software to run these interfaces has been pieced together one brick at a time by different programmers. It’s kind of like the way a modern house is built by disparate teams. The first team puts in the foundation, another group frames it, then the interior gets done by still another group. The house gets done alright, but it’s far from perfect. If the foundation team didn’t get the cement footings in the right place, the framing team compensates and somehow it all works out. But house building is simple compared to programming. Consider that the simple act of turning the volume up and down has a 17-page engineering document detailing everything a programmer needs to know and do. 17 pages. And that’s just the volume. Never mind the display, the remote control, the input switching, firmware updates, contingencies for everything imaginable. You get the idea of how complicated just building a simple interface can get.

Nearly 1 year ago our engineering director, Matt, came to the management team and said it was time to throw out all the years of programming and start fresh. He proposed we build a new operating system from the ground up, one that was easy to modify, stable, robust, applicable to any of our products as a common platform. It would require thousands of hours and patience. And, at the end of the journey, we’d have a shiny new and boring operating system. One that just worked without flaws. One that was easy to update in the field.

So, it was an unexpected pleasure when the boys handed me the finished product and it just worked without fanfare, without drawing attention to itself.

Boring, yet beautiful.