Which filter? I don't think there is any filter that can be removed from an oversampling SD DAC.
The ESS hyperstream concept is a marketing driven hot air balloon, there's nothing fundamentally different in an ESS DAC compared to any other oversampling delta sigma DACs. The modulator width and randomly selecting one from a pool of 1024 at each conversion cycle are just implementation details. Maybe there's more than I am aware of, but I don't think so.
The IF means either having a USB stack on the controller written to satisfy the non-tolerant MS WASAPI UAC2 driver, or having access to the source code to fix it. If so, the windows uac2 seems to be a decent USB async class 2 driver, bitperfect and accepting any samplerate the device reports, not only some hard-coded list of standard multiples. Certainly suitable for a measurement device with high samplerates and 24/32bit samples, no commercial ASIO driver required.
https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg-5.html#post6725023
https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg-5.html#post6725714
I think he says they are getting rid of this filter problem, in any case a very nice presentation i linked the the time to the filter audibility but I recommend the whole videoRMAF 11 Noise-Shaping Sigma-Delta Based DACs, Martin Mallison, CTO, ESS Technology - YouTube
Very interesting talk. Pretty sure some will not like some of what Mallinson says.
And I am pretty sure some will like a lot some of what Mallinson says, as long as it supports their subjective claims. Sorry, I'm not buying anything but hard data, everything else is marketing drivel, even if it comes from a reputable engineer. Engineers have to make a living too, and sometimes such talks are part of the cost of being in business.
Unfortunately I've already seen enough crap about the Hyperstreaming Technology to take anything else from ESS, in particular communicated at something like RMAF, with quite a bit of salt.
Unfortunately I've already seen enough crap about the Hyperstreaming Technology to take anything else from ESS, in particular communicated at something like RMAF, with quite a bit of salt.
Sorry but I have not insulted anyone, you have not understood what I meant with the word "consistency", nothing to do with your knowledge and experience.
I think you are a few months behind, oscillators GB is gone.
Next time I will sell a FIFO buffer (just like the one sold on this thread) and a DAC.
Or maybe a pair of DACs since I'm planning to design a board for the AD5791 (I love all the scorned devices on ASR website).
This was the consistency I asked for, now you are consistent.
Maybe to be completely consistent you should insult everyone who bought the FIFO buffer sold on this thread just as you repeatedly insulted those who bought the "-130dBc @ 1Hz clock phase noise clock" (although I have not reached similar performance with my oscillators).
But it is already a step forward.
Sorry but you don't need a FIFO buffer in USB async mode, just use the 30 USD device I have linked.
The USB to I2S board will feed the DAC directly with its master clock.
Nothing to clean up before feeding the DAC here, the cleaning is performed by the interface board.
And if you use an ESS DAC in async mode (with the 100MHz clock on board and its DPLL) no clean up is needed.
It seems to me that Ian has already done this with his FifoPi and his ESS DAC dual mono.
You can disable the Sabre DPLL and feed the DAC in true sync mode.
Ian, please correct me if I was wrong.
I'm just having a fight with a dotnet application that uses the NAudio package to generate samples in order to make the DAC playing DC signals at different amplitudes.
Substantially I would switch-on each bit one by one (only one bit on at a moment).
There is no way to play the sample at the right amplitude, always the sample is rendered at the max amplitude, although I have checked the wave stream bit by bit and it was correct.
I have tried direct sound and WASAPI, no success.
Asio driver to be tested.
Windows is a pain, just like one of its prophet (better if I avoid to name him but i believe you have understood who I'm pointing out).
And, of course, an ASRC with it's PLL is deemed insufficiant.
It's funny to see how, while strongly suggesting that a PLL is an inferior solution for cleaning the clock jitter, and something like your low phase noise clock is so much better, you are at the same time willing to accept the ES9038 internal ASRC with it's DPLL.
It's funny to see how, while strongly suggesting that a PLL is an inferior solution for cleaning the clock jitter, and something like your low phase noise clock is so much better, you are at the same time willing to accept the ES9038 internal ASRC with it's DPLL.
Nothing to do with the part but the implementation is flawed. I'll be interested to see what you get.
Not quite, I meant that if you use the ESS DAC in async mode there is no reason to use a FIFO buffer to clean up something because what you clean will be dirty again by the local clock and by the DPLL of the DAC.
It's a question of consistency.
I know you have not yet understood, but I'm here to share my experience and my designs and not to sell something.
So unlike others who suggest using a FIFO buffer even when clearly not needed, I will never suggest a FIFO buffer to those who use the ESS DAC in async mode.
Having said that I would never use the DPLL of the ESS DAC in async mode, I would use this DAC in true sync mode.
I think you mix up the concepts here a bit...
FIFO with memory is for frequency missmatch fixing. A FIFO replaces the clock from the incoming source with an own internal one. If that clock has lower jitter than the incoming, the FIFO also cleans jitter of course. ASRC recalculates the incoming stream... Wanted - not really - no.
If you have a stream with the correct frequency or if you are master but the signal (clock really) has jitter - get a Potato flip-flop and re-clock; no need for fifo.
Why didn't they settle for one base frequency for the s/pdif interface instead of two? Why didn't they make it 2 way so that the receiver could be master? Why, o why?
//
Nothing to do with the part but the implementation is flawed. I'll be interested to see what you get.
The part itself seems to have a glitch issue since the MSB switches every zero crossing. Sign magnitude notation would help here.
I don't know how Shiit engineers have cured this issue and neither if the alleged issue was solved.
However I'm curious as well to understand how a industrial DAC can perform when used in audio application.
By default all of those methods are likely to fail. Windows Sound Engine will almost always resample the output stream unless certain conditions are met. WASAPI Exclusive Mode can bypass the resampler if the driver requests it (Exclusive Mode is not supported by most DAC drivers, although plain WASAPI may be supported). ASIO can also avoid being resampled, but only if the audio device is not automatically made the Windows Default Sound Device, nor made the Windows Default Communication Device. A green checkmark next to the audio device in the Windows Control Panel Sound applet indicates the device is set to one or both of the above defaults. Also, Windows may automatically reassign a device to one or both of the above defaults if the device USB cable is unplugged then plugged in again later.
Last edited:
There are two ways I have used to tell if resampling is occurring. The first was that a sound card I once had came with an app that showed the actual sample rate it was receiving from the driver. The other way is by listening. There have been a number of times I have noticed my custom AK4499 DAC sounded more distorted than normal (although I suspect many people might not notice the effect at first, and some dacs may obscure the effect with their own distortions). When I notice a distortion increase has happened I start thinking about what could be causing it, and at some point decide to check Windows sound settings for the device. That's happened enough times so that checking Windows is usually the first thing that gets looked at.
Last edited:
Maybe you are right.
I have just connected the oscilloscope at the output of the USB to I2S interface.
I have generated a 24 bit/192kHz DC sample at half the max amplitude (4194304), so only the MSB should be switched on (binary data attached).
When I play the sample by the Windows app the sample rate is reduced to 48kHz and several bits are on.
That's incredible, one has to get crazy to play the most simple signal (DC).
But this is the world of the Lord of the Blue Screen, the one I avoid to name.
I shouldn't have expected something that makes sense.
