Schiit Audio: Marketing vs Engineering

[amirm]

According to the designer, he knew it was there from the beginning, he just thought that a -120dB artifact wasn't likely to be audible. When it all blew up, he released a firmware change. (Added an offset in the digital filter.) If he'd done what most designers of multibit DACs do in that situation (add dither to mask it) no-one would have noticed in the first place.

I am not sure he understands what dither is when he says this: https://www.head-fi.org/threads/schiit-yggdrasil-impressions-thread.766347/page-161

"The glitch pointed out (and agreed to by me as glitch before my surgery) is DAC glitch proper to multibit DACs driven by 2s compliment math at zero crossings, already pointed out by one poster, but ignored by many on this thread in their haste to condemn the DAC. This glitch worsens with lowering decoded output on any mb DAC.

The rest of the world deals with this zero crossing phenomenon is by adding dither, which is random noise just above the level of the glitch. This can either be done on purpose digitally or accidentally with an overly noisy analog section."​

Dithering noise must be added prior to conversion. Adding noise in the final stage like the analog amp just adds noise. It does not dither (i.e. distortion remains).

Given this, I am not clear that he really knew the problem existed until it blew up online.

 

[Don Hills]

I do say "Uh-huh..." sometimes when I'm reading Mike's and Jason's posts.

 

[watchnerd]

Given this, I am not clear that he really knew the problem existed until it blew up online.

My recollection, which is certainly not perfect, was that upon the Stereophile review being published, Schiit / Mike basically said, "we're not sure what was going on with that sample, we're going to have to look at it and diagnose when it comes back".

 

[Cosmik]

The rest of the world deals with this zero crossing phenomenon is by adding dither
​

I don't think so. They use a sample and hold. But apparently Mike Moffatt has in the past said "sample-hold sounds like ***". So the story seems a bit inconsistent.​

 

[Cosmik]

Articles on glitch reduction/elimination:
https://e2e.ti.com/blogs_/b/analogwire/archive/2013/07/01/dac-essentials-glitch-be-gone
http://www.ti.com/lit/ug/tidu022/tidu022.pdf

 

[watchnerd]

I don't think so. They use a sample and hold. But apparently Mike Moffatt has in the past said "sample-hold sounds like ***". So the story seems a bit inconsistent.​

Here is Schiit's non-SH de-glitching:

 

[Cosmik]

Here is Schiit's non-SH de-glitching:

Yes, the idea that this is a firmware-curable thing..? By now, I have become far too cynical, and I begin dreaming up evil ideas as to how it might be done in a way that looks good on sine waves, but isn't strictly 'correct'... But that's just my own twisted imagination - of course they wouldn't really do that.

 

[Purité Audio]

Schitt chosen as a noun but turns out to be an adjective.
Keith

 

[Ken Newton]

Yes, the idea that this is a firmware-curable thing..? By now, I have become far too cynical, and I begin dreaming up evil ideas as to how it might be done in a way that looks good on sine waves, but isn't strictly 'correct'... But that's just my own twisted imagination - of course they wouldn't really do that.

Glitching is a very brief burst of wideband energy, which both manifests and disappears within less than a single digital audio sample interval. Most modern D/A converters specify glitch settling time as no longer than 200ns.

Firmware can only affect converter output on an whole sample interval basis. Recall that CD rate data has an native sample rate of 22us. Therefore, I can't readily think of any way whereby converter glitching can be corrected via firmware.

 

[watchnerd]

Glitching is a very brief burst of wideband energy, which both manifests and disappears within less than a single digital audio sample interval. Most modern D/A converters specify glitch settling time as no longer than 200ns.

Firmware can only affect converter output on an whole sample interval basis. Recall that CD rate data has an native sample rate of 22us. Therefore, I can't readily think of any way whereby converter glitching can be corrected via firmware.

I suspect people are using the term 'firmware' to include an update to the SHARC DSP software that follows the DAC chip in this implementation.

 

[Ken Newton]

I suspect people are using the term 'firmware' to include an update to the SHARC DSP software that follows the DAC chip in this implementation.

Yes, that's what I had assumed. Any DSP algorithm which alters the data sent to the converter can only control the converter at the system native sample rate. Glitching manifests at much LESS than an audio sample rate, so cannot be corrected by an algorithm which can only output corrections AT the system sample rate.

 

[watchnerd]

Yes, that's what I had assumed. Any DSP algorithm which alters the data sent to the converter can only control the converter at the system native sample rate. Glitching manifests at much LESS than an audio sample rate, so cannot be corrected by an algorithm which can only output corrections AT the system sample rate.

Okay, now I'm wondering how they fixed it...maybe they gave up on their "no store and hold" stance?

 

[Ken Newton]

Okay, now I'm wondering how they fixed it...maybe they gave up on their "no store and hold" stance?

I can only think it's some sort of post converter solution, meaning, is applied in the analog domain.

 

[watchnerd]

I can only think it's some sort of post converter solution, meaning, is applied in the analog domain.

Here is a post about it. Pretty vague:

https://www.computeraudiophile.com/forums/topic/37265-yggdrasil-glitch-fixed/

 

[Ken Newton]

It occurs to me that the glitch being shown may not be due to the internal bit-switching of the converter, which is what is usually being referred to as glitching in DAC specifications. Possibly, it may instead simply show non-monotonic LSB behavior of the converter chip, and Schitt is generically referring to that as a glitch?

Non-monotonic converter behavior can be substantially corrected in firmware via an look-up table holding offsetting data values corresponding to each potential input data word. This would require measuring each individual DAC unit's linearity and then programming it with it's own unique look-up table values.

 

[Don Hills]

Thanks Ken, that's my understanding of the problem and fix, based on Mike's descriptions.

 

[watchnerd]

It occurs to me that the glitch being shown may not be due to the internal bit-switching of the converter, which is what is usually being referred to as glitching in DAC specifications. Possibly, it may instead simply show non-monotonic LSB behavior of the converter chip, and Schitt is generically referring to that as a glitch?

Non-monotonic converter behavior can be substantially corrected in firmware via an look-up table holding offsetting data values corresponding to each potential input data word. This would require measuring each individual DAC unit's linearity and then programming it with it's own unique look-up table values.

Are you saying that this would have to be calculated for each unit individually?

If so, that doesn't seem like it would scale very well.

 

[amirm]

The issue as I understood it was the format conversion between output of the digital filter as implemented in the FPGA and the input to the Analog Devices DAC. Any such conversion needs to have dither for correct operation so not sure how they skipped that. It would also be fixable with a new FPGA image ("firmware") whereas any messing with analog output would not be.

 

[Ken Newton]

Are you saying that this would have to be calculated for each unit individually?

If so, that doesn't seem like it would scale very well.

Assuming that the glitch source which Schitt is addressing is due to some unit-to-unit converter non-linearity then each individual DAC would indeed need to be measured and offsetting data values computed and programmed into a firmware based look-up table unique to each individual DAC. That can be done totally via an computer controlled measurement and programming setup for mass production. It doesn't have to be performed by hand.

It's also possible that the non-linearity uniformly affects the converter chip output due to some design or maybe some manufacturing process flaw. This would enable identical look-up table correction values to be determined once then programmed repeatedly across all of the converter units, without individual measurement.

 

[mindbomb]

It occurs to me that the glitch being shown may not be due to the internal bit-switching of the converter, which is what is usually being referred to as glitching in DAC specifications. Possibly, it may instead simply show non-monotonic LSB behavior of the converter chip, and Schitt is generically referring to that as a glitch?

Non-monotonic converter behavior can be substantially corrected in firmware via an look-up table holding offsetting data values corresponding to each potential input data word. This would require measuring each individual DAC unit's linearity and then programming it with it's own unique look-up table values.

Ok, this is what I was thinking when I heard the explanation for the fix. The dac glitch I think was already addressed by having two dacs out of phase and switching between them to fast forward through the settling time. So with that out of the way, what we are seeing here is a gain error which was fixed through manually recalibrating the dac with offsets.