Hi,
Please does anyone have a practical experience with AK4493 in oct or hex sampling speeds, i.e. 384+kHz sample rates?
When MCLK is at least 128xFS and sampling speed (DFS0-2) at most quad, the DAC outputs correctly oversampled signal. When dropping MCLK to 96xFS and setting corresponding sampling speed to oct or hex, the DAC output waveform is broken.
This is 96kHz sine generated at 384kHz. The chip officially supports MCLK 49MHz, hence I can set MCLK=128xFS and the corresponding quad sampling speed. The output waveform is flawless (fig 1), detail showing the oversampled steps at fig. 2.
However, when using MCLK = 96xFS (correct ratio according to the datasheet http://d.zaix.ru/5cHC.pdf ) and the corresponding oct sampling speed, the DAC output waveform is broken (fig 3, fig 4).
The same occurs for the hex sampling speed (e.g. at 768kHz or even at 384kHz with MCLK = 64xFS). I am surprised nobody would have noticed such a weird behavior, but have not found anything being discussed about this. Well I have not found any technical discussion of using these chips at fs > 192kHz (but they are used in commercial soundcards supporting up to 768kHz). I asked at eevblog, no response.
Thank you very much for any hints and recommendations.
Pavel.
Please does anyone have a practical experience with AK4493 in oct or hex sampling speeds, i.e. 384+kHz sample rates?
When MCLK is at least 128xFS and sampling speed (DFS0-2) at most quad, the DAC outputs correctly oversampled signal. When dropping MCLK to 96xFS and setting corresponding sampling speed to oct or hex, the DAC output waveform is broken.
This is 96kHz sine generated at 384kHz. The chip officially supports MCLK 49MHz, hence I can set MCLK=128xFS and the corresponding quad sampling speed. The output waveform is flawless (fig 1), detail showing the oversampled steps at fig. 2.
However, when using MCLK = 96xFS (correct ratio according to the datasheet http://d.zaix.ru/5cHC.pdf ) and the corresponding oct sampling speed, the DAC output waveform is broken (fig 3, fig 4).
The same occurs for the hex sampling speed (e.g. at 768kHz or even at 384kHz with MCLK = 64xFS). I am surprised nobody would have noticed such a weird behavior, but have not found anything being discussed about this. Well I have not found any technical discussion of using these chips at fs > 192kHz (but they are used in commercial soundcards supporting up to 768kHz). I asked at eevblog, no response.
Thank you very much for any hints and recommendations.
Pavel.
Attachments
Interesting!
I haven't tried it with the AK4493, but I tried something similar with the AK4490.
I made a test, using the RTX6001 with a modified USB interface FW, where I set it to 384 kHz. The result was like your fig 3. In this design I use a 24.576 MHz MCLK, so a 49.152 will require some modifications.
From my measurements my conclusion was that 384 kHz was not worth chasing, given an output like fig 3, but if something like fig 1 can be achieved, it is of course a different story.
It is strange that 49.152 MHz is supported at 96, 192 and 768 kHz sample rates, but not at 384 kHz. It could perhaps be an error in the datasheet. It could of course also be that there is some (marginal?) timing issue at 384 kHz.
The AK4490 does not support 49.152 MHz as the AK4493 does.
Do you have a possibility to measure the idle noise floor up to 200 kHz with a sample rate of 384 kHz? It would be interesting to know if it stays flat as it does at 192 kHz sample rate.
I haven't tried it with the AK4493, but I tried something similar with the AK4490.
I made a test, using the RTX6001 with a modified USB interface FW, where I set it to 384 kHz. The result was like your fig 3. In this design I use a 24.576 MHz MCLK, so a 49.152 will require some modifications.
From my measurements my conclusion was that 384 kHz was not worth chasing, given an output like fig 3, but if something like fig 1 can be achieved, it is of course a different story.
It is strange that 49.152 MHz is supported at 96, 192 and 768 kHz sample rates, but not at 384 kHz. It could perhaps be an error in the datasheet. It could of course also be that there is some (marginal?) timing issue at 384 kHz.
The AK4490 does not support 49.152 MHz as the AK4493 does.
Do you have a possibility to measure the idle noise floor up to 200 kHz with a sample rate of 384 kHz? It would be interesting to know if it stays flat as it does at 192 kHz sample rate.
Jens, thanks. I am glad (and very disappointed at the same time) that you confirm the corrupted filter. My feeling from the AK4490/3 series is that the higher samplerates were hacked into older models just for marketing purposes. The datasheet suggests so, the oct and hex modes are not detailed, no filter measurements, nothing.
AK4493 officially does not support 49MHz MCLK for 384kHz either, but works fine. I tested at 460kHz at 128xFS (MCLK some 59MHz), my piece runs fine. At 512kHz (MCLK 65MHz) I was already getting random dropouts somewhere in the digital part of the DAC (my I2S runs OK up to 1024kHz frameclock/49MHz bitclock).
The problem with the oct/hex waveforms is no analog filter can fix such a distorted output.
Still I do not see why removing one x2 layer of oversampling should produce such a distortion. It looks like a bug somewhere in the silicon...
Unfortunately not (yet).
What does actually the quad/octo/hex mean internally? I would understand this:
MCLK=768xFS => sigma/delta 24bits => 32x oversampling - normal
MCLK=384xFS => 16x oversampling - double
MCLK=192xFS => 8x oversampling - quad
MCLK=96xFS => 4x oversampling - oct
MCLK=48xFS => 2x oversampling - hex
But how are the intermediate FSx128, x64, x512 etc. handled? Does it run the sigma/delta conversion at 16bits (x128 is quad according to the datasheet, that would be 128/16 = 8)? Then x1024 would run at 32bits (1024/32 = 32), x1152 no idea (36bits?).
AK4493 officially does not support 49MHz MCLK for 384kHz either, but works fine. I tested at 460kHz at 128xFS (MCLK some 59MHz), my piece runs fine. At 512kHz (MCLK 65MHz) I was already getting random dropouts somewhere in the digital part of the DAC (my I2S runs OK up to 1024kHz frameclock/49MHz bitclock).
The problem with the oct/hex waveforms is no analog filter can fix such a distorted output.
Still I do not see why removing one x2 layer of oversampling should produce such a distortion. It looks like a bug somewhere in the silicon...
Do you have a possibility to measure the idle noise floor up to 200 kHz with a sample rate of 384 kHz?
Unfortunately not (yet).
What does actually the quad/octo/hex mean internally? I would understand this:
MCLK=768xFS => sigma/delta 24bits => 32x oversampling - normal
MCLK=384xFS => 16x oversampling - double
MCLK=192xFS => 8x oversampling - quad
MCLK=96xFS => 4x oversampling - oct
MCLK=48xFS => 2x oversampling - hex
But how are the intermediate FSx128, x64, x512 etc. handled? Does it run the sigma/delta conversion at 16bits (x128 is quad according to the datasheet, that would be 128/16 = 8)? Then x1024 would run at 32bits (1024/32 = 32), x1152 no idea (36bits?).
Last edited:
The AK4490 does not support 49.152 MHz as the AK4493 does.
According to datasheet AK4490 supports 49.152 MHz as well. Actually even at 384kHz.
I'm currently using oct-mode with AK4490 fed by AK4147. The MCLK is 24.576MHz though. Have not looked at the output using scope but THD+N figures are flawless.
Last edited:
Ah, you're right! I looked at table 6, where it is not listed, but it is listed in table 10.
The support at 384 kHz makes is even more likely that the missing official support for 384 kHz/49.152 MHz for the AK4493 is a datasheet error.
The support at 384 kHz makes is even more likely that the missing official support for 384 kHz/49.152 MHz for the AK4493 is a datasheet error.
The support at 384 kHz makes is even more likely that the missing official support for 384 kHz/49.152 MHz for the AK4493 is a datasheet error.
Or they found out that it does not actually work with either AK4490 or AK4493 and corrected this on AK4493 datasheet only 😀
I'm currently using oct-mode with AK4490 fed by AK4147. The MCLK is 24.576MHz though. Have not looked at the output using scope but THD+N figures are flawless.
That's very interesting. Are you sure it's really oct mode? AK4117 runs at 192kHz, at 24.576MHz that would be 128Fs => quad. Or 384kHz at 64Fs, does AK4117 handle that? The reason I am asking for confirmation is your experience would be opposite to mine and Jens's, and perhaps some setup of the DAC could fix that (which would make me happy 🙂 ). Thanks.
Or they found out that it does not actually work with either AK4490 or AK4493 and corrected this on AK4493 datasheet only 😀
My piece runs fine at 384/49MHz. IMO there is no reason not to, if the chip can run the delta/sigma conversion at 49MHz master clock. It would be unusual that the oversampling filter could oversample 768kHz for the 49MHz MCLK and not the 384kHz.
That's very interesting. Are you sure it's really oct mode? AK4117 runs at 192kHz, at 24.576MHz that would be 128Fs => quad. Or 384kHz at 64Fs, does AK4117 handle that? The reason I am asking for confirmation is your experience would be opposite to mine and Jens's, and perhaps some setup of the DAC could fix that (which would make me happy 🙂 ). Thanks.
Typo. I meant AK4137. I have used this dac for audio so I have not measured it using signals above 20kHz. But I have not seen anything wrong with even 20kHz THD+N spectrums.
I've just checked that with the 4490 and this error happens at any sample rate and OS ratio, as far as those are exercised in the ADI-2 Pro
This is AK4493 20k sine at 384kHz at:
1) FSx128 (49MHz), quad mode, at DAC output
2) FSx64 (24MHz), oct mode, at DAC output
3) FSx64 (24MHz), oct mode, at filter output (f=440kHz)
The "wrinkles" at oct mode are at 384kHz - fig 4. Seeing that would require measurement BW of APx555 (1MHz), IMO.
1) FSx128 (49MHz), quad mode, at DAC output
2) FSx64 (24MHz), oct mode, at DAC output
3) FSx64 (24MHz), oct mode, at filter output (f=440kHz)
The "wrinkles" at oct mode are at 384kHz - fig 4. Seeing that would require measurement BW of APx555 (1MHz), IMO.
Attachments
This is AK4493 20k sine at 384kHz.
Are you using parallel or serial mode?
I'm using serial mode (or register mode). And my scope shot was after the filter (single LM4562 LPF).
Last edited:
KSTR: Does it mean ADI outputs the distortion even at < 384kHz samplerates?
Yeah, the discontinuity is always with the samplerate frequency, at oct and hex modes on my AK4493.
Guys, thanks for these tests, we are getting somewhere 🙂
There is a beating with sample rate. So 95.999kHz at 384k gives a 1Hz wandering pattern
Yeah, the discontinuity is always with the samplerate frequency, at oct and hex modes on my AK4493.
Guys, thanks for these tests, we are getting somewhere 🙂
I'm using serial mode (or register mode). And my scope shot was after the filter (single LM4562 LPF).
I2C control, register mode. Please can you check the DAC output? But I believe it will be OK, the filter could not fix what comes out of my DAC.
Please can you post your key register settings? Thanks a lot. Your setup looks correct.
This is a system chip thing.
What we see is the effect of disabled digital filter, so staircase "NOS" mode. It just doesn't have enough time to settle because of the inherent filters in the switched capacitor DAC core.
What we see is the effect of disabled digital filter, so staircase "NOS" mode. It just doesn't have enough time to settle because of the inherent filters in the switched capacitor DAC core.
- Home
- Design & Build
- Equipment & Tools
- AK4493 at oct/hex sampling speeds - oversampling filter issue?