pkr708: check these undocumented registers Sabre DAC Datasheet: The Missing Parts | H i F i D U I N O
Yes, less, but if the music signal happens to wander just around the critical level then it can modulate the noise floor.
(many R2R's tend to get bumpy THD+N vs level plots too, when signal crosses the boundary where next 2x element jumps in, but there it's mostly THD because the error cannot be whitened)
Does it really fall down, or the SNR just improves because the signal itself comes stronger? The THD+N vs level plots look like the noise stays pretty much at the new level, as expected. Although maybe improving a little possibly due to some modulator dither kicking in and reducing the error.
Thanks!
Yes, see table in .xlsx attached to post #2351 - measurement of best and worst channel of my DAC module.
The integrated THD+N error signal amplitude, which is about ~1.4uV for very low level signals, suddenly jumps to 8.35uV on -35dBFS, but again falls to ~3.3uV near full scale (where majority of it is probably formed by THD itself, not noise).
Hi Paul,
I was dealing with the same problem, thinking that it is my design's issue, until I've been told about your post.
I've reached over -124dB THD and ~1.6uVrms audio band noise, which yields about 121dB DNR (my module is 8 channel with 1.6V output voltage). But interestingly, I found out that every channel has different full-scale THD+N, varying from -113 to -116.5dB. I spent tens of hours trying to solve it!
After reading your post, I sat again to R&S UPV and measured THD+N vs. amplitude and got the same result as you. There really is a bug manifesting itself between -35 and -36dBFS by steep noise rise, while THD level is not affected. However, I think it is a output, not input stage bug, because it acts differently on each channel.
Channels 2 and 6 are performing best, while 1, 7 and 8 are the worst. All measurements has been made with I2S input in asynchronous mode and the bug is present with both cheap Fox and high-quality PLEtronics MCLK oscillator.
Unfortunatelly, I can't (or at least don't know how to) make a plot of noise vs. DC level (in dBFS). Could you try to do it on your AP? I think there may be only single (or few) problematic DC level/s corresponding to certain input data levels, which could be filtered out by DSP to solve this problem.
I've sent a message to ESS tech support more than week ago... still no reply.
BR,
Pavel
Thanks for your input.
To my system, the issue did not appear sometimes when I power my DAC up.
In that case, the noise for whole range is ultra clean. as you can see from my measurement.
But, I am afraid that ESS will not reply a single word to this issue. Because many customers are using ES9018 in their products. Like WEISS, etc.
I think it will not affect listening most of the time, but I insist on my standard. This bug can not meet my requirement unless I can find a stable way to avoid this.
Thank you.
BR
Paul Lu
In the blog post by Mr. Kakuta of AIT Lab in Japan, as "shinja" explained above, he reported that the emergence of spurious he observed was not a stable event.
At each power-on, the spurious appeared or not appeared.
He imagined a possible variation in timing of internal initialization of DPLL after each power-on might caused the problem.
Paul's post reminded me of the report by Mr. Kakuta.
Last edited:
My main system uses ES9018S chips in a synchronous master clocking scheme with 45/49 MHz low phase noise oscillators.
Only for such conditions as MCLK freq=256 x fs, DPLL Nobandwidth setting brings an output sound with periodic unlock events of which interval is constant. As for 45 MHz master clock, the interval is appoximately 24 seconds.
In spite of the scratch noise-like interrupt, the sound quality with DPLL Nobandwidth is superior and I love it. It is the best sound the DAC chip provides.
Does anyone here experience the DPLL Nobandwidth sound as well?
Only for such conditions as MCLK freq=256 x fs, DPLL Nobandwidth setting brings an output sound with periodic unlock events of which interval is constant. As for 45 MHz master clock, the interval is appoximately 24 seconds.
In spite of the scratch noise-like interrupt, the sound quality with DPLL Nobandwidth is superior and I love it. It is the best sound the DAC chip provides.
Does anyone here experience the DPLL Nobandwidth sound as well?
I found wolfson suggest DC sweep test to check how DEM work as expected.
http://www.wolfsonmicro.com/media/77029/Design_Eval_AudioDAC_Whitepaper.pdf
see page 4(85)
It is interesting that DEM have similar characteristics to noise shaping ,their noise frequency responce(?) and idle pattern problem.
I have not known latter.
http://www.wolfsonmicro.com/media/77029/Design_Eval_AudioDAC_Whitepaper.pdf
see page 4(85)
It is interesting that DEM have similar characteristics to noise shaping ,their noise frequency responce(?) and idle pattern problem.
I have not known latter.
I second this question and, in addition, would love to know, is it so, or not. There's virtually no info on what this "true/pseudo" means and how it correlates with quantizer depths. In early posts Russ said that "true" is not available beyond 6 bits; the experiments did show it is.
Could you please descramble me on this matter? Many thanks!!!
Hi Bunpei
As I know from your previous posts, you may have a quite extended experience with the digital files structure.
I have a very precise question: there is (may be) a characteristic structure for how the silence/pause is represented in a digital file, versus the rest of the contiguous (compact) analogue coded (originally analogue to digital converted) digital file?
I mean it have to be a difference in how is represented the information in a continuous flow of bits coded at the recording, and the added silence just after the last bit of information of that file (for pause reasons, or so). There is not here about the silent passages of a recording (inside a digital file), but the so called silence, when there is no more information to be streamed into the (DAC) system. It seems to me that it may be streamed a kind of information anyway, until the mute is activated, or another conversion of a next digital file it starts.
What I ask this question?
I have noticed recently, while experimenting with ES9018, that it behave different (resulted outputted sound), just after the last bit of information is decoded (converted), and when this supposedly added silence starts. After this variable in time "silence" (pause between files), it may be started the streaming of another file (previously it was read it its header), or it is turned on the Mute mechanism (the playback is stopped).
Here it is happen something, which lead me to the conclusion that it have to be a different digital structure, in how these events are digitally represented. I only need a confirmation (or not) at this hypothesis ...
I do hope I succeeded to make me understood with this text here (maybe a little bit out of topic)...
Thanks for your or another one`s eventual replay.
As I know from your previous posts, you may have a quite extended experience with the digital files structure.
I have a very precise question: there is (may be) a characteristic structure for how the silence/pause is represented in a digital file, versus the rest of the contiguous (compact) analogue coded (originally analogue to digital converted) digital file?
I mean it have to be a difference in how is represented the information in a continuous flow of bits coded at the recording, and the added silence just after the last bit of information of that file (for pause reasons, or so). There is not here about the silent passages of a recording (inside a digital file), but the so called silence, when there is no more information to be streamed into the (DAC) system. It seems to me that it may be streamed a kind of information anyway, until the mute is activated, or another conversion of a next digital file it starts.
What I ask this question?
I have noticed recently, while experimenting with ES9018, that it behave different (resulted outputted sound), just after the last bit of information is decoded (converted), and when this supposedly added silence starts. After this variable in time "silence" (pause between files), it may be started the streaming of another file (previously it was read it its header), or it is turned on the Mute mechanism (the playback is stopped).
Here it is happen something, which lead me to the conclusion that it have to be a different digital structure, in how these events are digitally represented. I only need a confirmation (or not) at this hypothesis ...
I do hope I succeeded to make me understood with this text here (maybe a little bit out of topic)...
Thanks for your or another one`s eventual replay.
Last edited:
Thanks for replay.
It is in that "area" I asked about... In normal use (normal playback), there is not audible that hiss in pauses. It may be because the mute become active. But it is a short time before another playback is started, or just before the mute become active, where I can notice a different behaviour, after the streamed bits come to end into the DAC.
Actually this silence it should be a zero bits sequence, but I just wonder why is different treated by the DAC chip, than the same "silence" inside the digital file (silent passages in the recording). It looks like the DAC detect different these sequences, and react (convert to analogue) in a different way. This behaviour it become obvious when the chip is overclocked (the highest/higher clock frequencies)...
As I can experience, increasing the clock frequency, it increase the precision in reproducing of all the sound components. Every single detail of the converted to analogue information, is to be heard. Just amazing sounds definition. The side effect of this very much increasing in the sounds details, is a kind of fine crackles audible only in this kind of pause/silence passages, I referred in my previous post. As long the digital file is streaming into the DAC, no matter its zero/silent passages, the analogue conversion is just fine. No any additional noises, but extremely well reproduced sounds, to the finest details. As the digital file streaming stops/ends, and start that, in my opinion, added silence/pause (on the end of the playback file), the fine cracklings become obvious. That because my conclusion that it may be a difference in the digital structure of that so called "silence" sequence.
It looks to me that the analogue reproduction is so high in fidelity that it make noticeable some very fine imperfections present into that added at recording silence/pause between songs...
As long as conversions are going into the DAC chip, no any such crackles are to be heard, but only after the conversions stops...
This (very reproducible) phenomenon it become noticeable as the DAC clock frequency goes over a safe level (the sound precision increase always as well). Then the DAC just stop working, after out of range (too high) clock frequency.
It is in that "area" I asked about... In normal use (normal playback), there is not audible that hiss in pauses. It may be because the mute become active. But it is a short time before another playback is started, or just before the mute become active, where I can notice a different behaviour, after the streamed bits come to end into the DAC.
Actually this silence it should be a zero bits sequence, but I just wonder why is different treated by the DAC chip, than the same "silence" inside the digital file (silent passages in the recording). It looks like the DAC detect different these sequences, and react (convert to analogue) in a different way. This behaviour it become obvious when the chip is overclocked (the highest/higher clock frequencies)...
As I can experience, increasing the clock frequency, it increase the precision in reproducing of all the sound components. Every single detail of the converted to analogue information, is to be heard. Just amazing sounds definition. The side effect of this very much increasing in the sounds details, is a kind of fine crackles audible only in this kind of pause/silence passages, I referred in my previous post. As long the digital file is streaming into the DAC, no matter its zero/silent passages, the analogue conversion is just fine. No any additional noises, but extremely well reproduced sounds, to the finest details. As the digital file streaming stops/ends, and start that, in my opinion, added silence/pause (on the end of the playback file), the fine cracklings become obvious. That because my conclusion that it may be a difference in the digital structure of that so called "silence" sequence.
It looks to me that the analogue reproduction is so high in fidelity that it make noticeable some very fine imperfections present into that added at recording silence/pause between songs...
As long as conversions are going into the DAC chip, no any such crackles are to be heard, but only after the conversions stops...
This (very reproducible) phenomenon it become noticeable as the DAC clock frequency goes over a safe level (the sound precision increase always as well). Then the DAC just stop working, after out of range (too high) clock frequency.
Last edited:
Hi Coris!
I'm not any expert of digital sources while "signalyst" who appeared recently on this thread is a genuine expert. (He is an author of HQ Player.)
I'm afraid that your question is not precise enough.
Is your focus on PCM over I2S or DSD? The way of representation and handling of silence in the case of DSD is quite different from that of PCM.
Are you talking about sound data stored on a digital file or electronic signal input to DAC chip device? In the case of I2S signals, you must consider presence of clock signals, especially for BCLK in addition to serial audio signals.
In general, a handling of series of zero audio data on I2S or SPDIF depends on a type of DAC architecture. As for a DAC of delta-sigma modulator architecture, a long continuous zero data must be rejected. I think your question is ES9018 specific.
Bunpei
I'm not any expert of digital sources while "signalyst" who appeared recently on this thread is a genuine expert. (He is an author of HQ Player.)
I'm afraid that your question is not precise enough.
Is your focus on PCM over I2S or DSD? The way of representation and handling of silence in the case of DSD is quite different from that of PCM.
Are you talking about sound data stored on a digital file or electronic signal input to DAC chip device? In the case of I2S signals, you must consider presence of clock signals, especially for BCLK in addition to serial audio signals.
In general, a handling of series of zero audio data on I2S or SPDIF depends on a type of DAC architecture. As for a DAC of delta-sigma modulator architecture, a long continuous zero data must be rejected. I think your question is ES9018 specific.
Bunpei
Hi Bunpei
Thanks for replay.
Yes, my question is ES9018 related. I refer too, at an digital file stored on a support, and play it back through a software player (USB interface in my case).
Well, I have observed this issue more carefully, and I can say that some few crackles are present too in the silence passages of an recording, but are much more frequent in a longer zero bits sequence. It seems to me that such disturbances on the analogue audio signal, it have a connection with the zero bits presence/detecting in the streamed file, at the DAC chip conversions. This problems appear at a higher clock frequency, than the safe ones. It may be normal such behaviour, as the clock is higher than the specified one, and yet over a frequency which works well for the chip.
Ideally, I would like to keep the higher clock frequency, as the sound improve quite much (I do not know the real explanation to this improvement), but in the same time side (negative) effects occur. As these cracklings, when zero bits predominate in the data streamed file.
I think it become shaped in my mind a possible explanation for this behaviour...
For practical reasons, the immediate cure for the problem is to lower the clock frequency under the level which it may trigger such disturbances.
Thanks for replay.
Yes, my question is ES9018 related. I refer too, at an digital file stored on a support, and play it back through a software player (USB interface in my case).
Well, I have observed this issue more carefully, and I can say that some few crackles are present too in the silence passages of an recording, but are much more frequent in a longer zero bits sequence. It seems to me that such disturbances on the analogue audio signal, it have a connection with the zero bits presence/detecting in the streamed file, at the DAC chip conversions. This problems appear at a higher clock frequency, than the safe ones. It may be normal such behaviour, as the clock is higher than the specified one, and yet over a frequency which works well for the chip.
Ideally, I would like to keep the higher clock frequency, as the sound improve quite much (I do not know the real explanation to this improvement), but in the same time side (negative) effects occur. As these cracklings, when zero bits predominate in the data streamed file.
I think it become shaped in my mind a possible explanation for this behaviour...
For practical reasons, the immediate cure for the problem is to lower the clock frequency under the level which it may trigger such disturbances.
Last edited:
Hi, Coris!
Have you already read a data sheet of ES9018 and posted your previous question?
If not, I strongly recommend you make a Google search with such a phrase "ES9018 automute" and read the document appeared at the top of the listing.
The section you may find useful is "Zero detect".
Have you examined a register setting of ES9018 of your concern?
It's quite easy to read and interpret the meaning of the setting by connecting a simple Arduino system to the chip.
Bunpei
Have you already read a data sheet of ES9018 and posted your previous question?
If not, I strongly recommend you make a Google search with such a phrase "ES9018 automute" and read the document appeared at the top of the listing.
The section you may find useful is "Zero detect".
Have you examined a register setting of ES9018 of your concern?
It's quite easy to read and interpret the meaning of the setting by connecting a simple Arduino system to the chip.
Bunpei
A digital circuit is only guaranteed to give correct results if the clock frequency is within spec... In your case, since you overclock it, some of the calculations done inside the chip will sometimes give the wrong result, which would result as audible noise, glitches or pops as you describe. So, no voodoo here.
When the recording is silent but automute isn't active, you hear these errors, as you describe.
When playing music it will add errors to the played samples. Maybe it sounds better, who knows, some types of distortion can indeed sound pleasant !
Another question(s). With your permission...
I have an ES9018 chip configured in a unknown (for me) software environment (firmware). Its Lock pin is always on as the chip is powered up. Is this normal?
It can be set it up its registry to have a lock up on everything and always? Else, the chip is working very well on both PCM and DSD... But shows permanently Lock.
Anybody knows the current capabilities for Automute and Lock output pins?
Thanks for eventual replay.
I have an ES9018 chip configured in a unknown (for me) software environment (firmware). Its Lock pin is always on as the chip is powered up. Is this normal?
It can be set it up its registry to have a lock up on everything and always? Else, the chip is working very well on both PCM and DSD... But shows permanently Lock.
Anybody knows the current capabilities for Automute and Lock output pins?
Thanks for eventual replay.
Hi, Coris!
You seldom answered to my additional questions. You described nothing about your source signal characteristic.
I guess your noise problem might be nothing to do with your out-of-specification overclocking. Your overclocking is just 27 x 4 = 108 MHz, isn't it?
As for secure locking, there is no explicit register to make a lock permanent. Your heavily modded OPPO might adopt a safe DPLL Bandwidth register setting. As far as a BCLK is given to ES9018 properly and unchanged, the chip can easily maintain the locked status.
There is no description about physical specification of lock status output pin in the datasheet. Instead, you will find 390 ohm resistor in serial to LED in a schematic of ES9008 2ch demo board. This means 8mA is typical.
You seldom answered to my additional questions. You described nothing about your source signal characteristic.
I guess your noise problem might be nothing to do with your out-of-specification overclocking. Your overclocking is just 27 x 4 = 108 MHz, isn't it?
As for secure locking, there is no explicit register to make a lock permanent. Your heavily modded OPPO might adopt a safe DPLL Bandwidth register setting. As far as a BCLK is given to ES9018 properly and unchanged, the chip can easily maintain the locked status.
There is no description about physical specification of lock status output pin in the datasheet. Instead, you will find 390 ohm resistor in serial to LED in a schematic of ES9008 2ch demo board. This means 8mA is typical.