Yeah, my bad. Brain fart big time. That business was in reference to another post I was still contemplating. Nevermind...
Please let be explain about the clocks. There may be multiple devices in a dac system, say a dac chip, an FPGA, and an ASRC such as SRC4392 or AK4137. Currently in most systems they would all have their own clock oscillators. Turns out that may not be the best way. Synchronizing the clocks in particular ways can help with making sound quality improvements.
Test equipment isn't cheap, unless you're comparing to high-end cars
. I'm not really good at finding the gems on eBay.
Hmm, I don't know. I'd almost go as far to say that only in a lazy or poorly designed system would they have their own audio peripheral clocks. A sane device would have one master and run the rest as I2S slaves. An ASRC is mainly useful when you need to bridge clock domains.
There are only two good reasons to use an ASRC in a DAC box, IMO -
1. Your source / transport is a different clock domain (SPDIF input and you don't want to do the PLL / VCXO option).
2. Your DSP or filter block only operates at one rate.
You should be careful not to conflate audio clocks with non-audio clocks also. An FPGA or MCU core might be clocked by a 12 or 25 MHz XO but the audio clocks are provided to the peripheral.
You also don't describe at all what synchronizing these mystery clocks will do.
Well, that would make DAC-3 poorly designed, at least in the sense of their system clocks, which may not be entirely non-audio (since they are digital devices not analog).
What I had in mind myself is syncing the master clocks of each device which tend to run at higher frequencies than the I2S clocks. It matters, at least in the one case where I have done some experimentation. There is a bit more to the story which I have described in the ES9038Q2M board thread.
Regarding your point (2.), that may be part of it in some designs. AK4137 can do PCM -> DSD conversion at the same time as upsampling. Both AK4137 and SRC4392 can be useful for jitter reduction if needed, not just for reclocking a foreign transport clock.
The direction I'm going at the moment is that a good dac should be able to handle any common interface type well, and without excessive processing delays. In practice that means USB and SPDIF/TOSLINK/AES support, and no FIFO jitter removers. Probably it means the dac should run in synchronous mode for USB, and in ASRC mode (if Sabre) for SPDIF. The latter is harder to deal with and synchronous clocking can help.
Last edited:
Ran out of time on my last post #14484, and would like to add:
For some dac designs, its probably best to upsample everything to a one non-standard clock frequency, and then run the dac in ASRC mode (if ESS), or synchronous with the non-standard clock (if AKM). The reason is to help make possible a better external interpolation filter, since the non-standard upsampling creates an opportunity for a more relaxed interpolation filter transition band, thus allowing better optimization of other parameters (since design always has trade offs).
For some dac designs, its probably best to upsample everything to a one non-standard clock frequency, and then run the dac in ASRC mode (if ESS), or synchronous with the non-standard clock (if AKM). The reason is to help make possible a better external interpolation filter, since the non-standard upsampling creates an opportunity for a more relaxed interpolation filter transition band, thus allowing better optimization of other parameters (since design always has trade offs).
^And it's generally not hard to do that sort of resampling, and, if you'd like volume cut to avoid inter-overs, in SOX. Or Foobar, for that matter (but try to use ASIO and have your sampling rates set accordingly).
John, pretty cool add in for their TEM. Looks like a really high end FEI that they've modified heavily.
John, pretty cool add in for their TEM. Looks like a really high end FEI that they've modified heavily.
Last edited:
You have some knowledge, but you don't fully understand what you're talking about here, sorry. Unless Benchmark instantiates another ASRC in the FPGA there is no way the FPGA has its own AUDIO clock.
Your experimentation without measurements is going to lead to whatever results your heart desires.
There is no reason you can't do this with a standard audio clock frequency and pick whichever one you want. The only reason you might do this is if you can't defeat the filters in the DAC and you don't like their transition band behavior.
Most DAC ICs don't share the same quirks as the ESS parts either. This might be the best way to go with an ESS part, but I would need to do some testing.
Adding ASRCs to a system when you already have the master clock local to the converter and fed back to the the source (USB RX) is not best practice in my opinion. Jitter, beyond the quality of the master clock, is not a concern in that setup. They do have merit for SPDIF inputs as you noted.
As an aside, I'd like to point out that a few years before the ESS DACs showed up, ASRC was considered heresy by many here. If you put an AD1896 in your box it would be mid-fi at best, if you used any of the older parts like CS8420 you would be chased away with pitchforks. Funny how that works, now that some boxes with 5-figure price tags use it, it's suddenly okay. I never had a problem with it anyway, just to clarify my stance here.
Last edited:
No Chris. I would suggest reading everything John Siau has written or said about how DAC-3 works, read what it says about ESS DPLL in the data sheet, and read the ES9038Q2M thread for how what happened with separate clocks and synchronized clocks and why it matters. Its a long story, not something easily summarized here in a few short words. If you are interested in all the details, we can go to PM to set up a phone call to discuss it. And, as you will see an important measurement does improve.
Last edited:
Well, I'll check out the thread. Just because it improves something pathological with the ESS design doesn't mean it's how it should be done in every DAC. I don't like the ESS parts that much, honestly. The distribution sucks, the datasheets suck, and requiring an NDA to get the datasheet sucks.
Okay. Just a heads up: The thread does have a lot of off topic stuff, which can make finding things you want less than optimal. I would be happy to talk to you if that would be more convenient. I could also explain some things in more detail than I did in the thread, since I can't talk about certain things there that fall under the ESS NDA.
Last edited:
It's ok, I'll reach out to you via PM if I am curious about the ESS stuff. Right now I don't have a lot of interest in them. Thanks though.
That could be marginally better than the music they use in "nature" programs, still don't get it though, sorry
Those were just marketing names for first generation sigma delta converters. All obsolete 2 decades ago and all the manufacturers are using whatever they buy from TI, Cirrus, or AKM now.
Anyway, it’s a fundamental part of a sigma delta converter.
Last edited:
Bill, I think you hit the nail on the head in your first sentence. Once a dac system design gets good enough, its sound is defined by the filter. However, the preprocessing as you call it is necessary if the dac is to be good in the first place.
I never said the FPGA has its own audio clock. It can if needed though. For an arbitrary example, if it is programmed to do ASRC it can generate a new output clock at the new frequency. There are VCO and DPLL resources in the FPGA that can be configured for it.
Also, to the extent the FPGA runs on synchronous logic vs asynchronous, there is some digital granularity to how things get clocked through it, and the granularity can be traced back to its system clock. Does it matter? Maybe. If we need jitter down in the low tens of fs for the dac to accurately reproduce low level reverb tails, then the slightest output jitter from the FPGA to the dac can be a problem. According to Crane Song, a few 10's of fs does matter (and they are using AKM, not the accused quirky ESS chips).
I think it just means we need to remain open minded about how errors might crop up, and not make assumptions based on an over simplified model of how the FPGA actually works. I already did make that over-simplification error once between AK4137 and ES9038Q2M, and almost missed what nudging clock delay as little as 150ps could do to the sound quality. Apparently, Crane Song has found out a lot more, and I tend to believe they are onto something.
Last edited:
- Status
- Not open for further replies.