Most high-performance modern DAC ICs have differential outputs, even those targeting single-ended consumer applications. It’s a great way to reduce even-order nonlinearities in the chip’s conversion and output stages, and it gets you around 3dB better SNR.
To design for a differential (“balanced”) application, you can simply pass each side of the DAC chip’s outputs through a combined filter and buffer and let the downstream electronics do the summing.
To get a single-ended output, application guides and evaluation boards often show an added a summing stage to the above. But experience has shown that with voltage output DACs at least, things seem to work best when you use a single gain stage that both sums and filters the outputs of the IC.
When taking this approach, there’s a good amount of optimization you need to do that might not be initially apparent. But when the needed care is taken, it works very well. I suspect it works better than the filter-then-sum approach because the signal passes through fewer active cells (typically opamps). This leads not just to the potential for lower accumulated nonlinearity but also for less complex distortion spectra. These stated reasons are incredibly speculative at this point, but I am certain of what my ears consistently prefer.
So, there’s an easy solution when you want a differential output, and an almost as easy solution when you what a single-ended output. But what do you do when you want both? Initially it seems you have to decide which output gets priority: You either prioritize the differential output and convert that to single-ended or you prioritize the single-ended output and convert that to differential.
It turns out there’s an approach that as far as I know no one is yet using commercially that solves this dilemma perfectly.1I recently completed a design for a client using this approach that I’m expecting to be released soon. I’ll cover what that is in my next post.
In the third installment of this series, I want to talk about one of the device types you’re almost guaranteed to encounter in low-voltage audio: the rail-to-rail opamp. More specifically, I want to talk about the terminology around rail-to-rail opamps and the techniques used by IC designers to achieve rail-to-rail behavior. So let’s start by answering a fundamental question.
A few years ago, I developed an audio gain cell that was exceptionally fast for a fully discrete circuit and quite clean. That design ended up being adopted commercially, including by Audio by Van Alstine, who are using it in their DAC MK 5 and Vision preamplifier. I like to think that this gain cell is a key factor behind why the owner of a well-regarded manufacturer of luxury loudspeakers called the AVA DAC MK 5 one of the best sounding DACs he’d ever heard and a model for other manufacturer’s to live up to.
In an earlier post, I talked about how I entered the world of low-voltage audio and my commitment to delivering the best possible performance subject to that constraint. In this post I’d like to consider some strategies for generating power in your LV application.
I just discovered that I got a mention in Doug Self’s book The Design of Active Crossovers for the work I did a while back on loudspeaker crossovers. If you don’t know who he is, he’s one of the big names in British audio engineering. He’s done work for Cambridge Audio, TAG-McLaren Audio, and other respected brands. Feeling warm and fuzzy.
I’m bulk editing a bunch of KiCad footprints (a.k.a. modules) in a text editor. Said footprints have a tedit field, which turns out is a hex-coded timestamp. This means to properly edit a KiCad footprint in a text editor, you should update that field when you save it.
A one-liner for producing a hex-coded timestamp in Linux bash is:
In a previous installment, we took a dive into the this variable and how it behaves in different ES5 situations. In this installment, we’ll do the same but for so-called arrow functions, introduced in ES6.