There was a good joke...
We shall struggle a lot and again with the ESS secrecy policy, their very restrictive/limited outputted technical informations for the new chip, as for the previous ones, at their time.
We shall for sure face the same very strange policy of promoting new and performant products from this company...
As I can see so far, ESS very performant series of chips are still not yet widely implemented in end user products, and for sure their way of managing with the informations and a restrictive selling policy of the chips itself, it is a direct cause of a limited implementation in audio products out there...
I have same problem with "no bandwidth", how are you fixed that?
why I must using 176.4 only for "no bandwidth"?
please give me more detail, how to using "No bandwidth" mode.
thanks.
sorry i miss that,
ok, another question, are you found solution for fixed this "problem"?
Late to the party, I very much appreciate this suggestion so here is one data point: Running in asynchronous mode, changing register 11 DPLL from 'lowest' to 'no bandwidth' has improved B3 fidelity (with no drop-outs). The effect helps the speakers to 'disappear', providing almost a wall of sound instead of divided point sources. Also, bass response has changed a bit - slightly 'more forceful'.
Last edited:
Has anybody tried programming the FIR filter sections of the es9018? The es9018 seems more susceptible to outputting noise related to input clipping than the WM8741s that I used to use. The Wolfson chip had an anti-clipping digital attenuation mode that would apply 2dB of attenuation at the beginning of its input section. It would be nice if one could implement something like Wolfson's solution in the FIR filters of the es9018. I wonder if a) the FIR coefficients could be tweaked to achieve a lower incidence of annoying crackling noise, and b) what the trade-offs might be?
TIA for your thoughts and ideas.
TIA for your thoughts and ideas.
Yes, with some recordings that are mastered with high output levels, I get 'scratchiness' on some transients - especially noticeable with voice. [Example: 'Stay With Me' by Sam Smith] I can cure this by lowering volume in software, but then the SQ is less desirable. Better to do it all on the es9018, if possible. But before learning everything necessary to try, better to see if any others have accomplished this and learn from them.
Last edited:
Yes, with some recordings that are mastered with high output levels, I get 'scratchiness' on some transients - especially noticeable with voice. [Example: 'Stay With Me' by Sam Smith] I can cure this by lowering volume in software, but then the SQ is less desirable. Better to do it all on the es9018, if possible. But before learning everything necessary to try, better to see if any others have accomplished this and learn from them.
Dig your (pre)amp. No living DAC can go beyond 0dB physically - well, unless it's a mytek with +6dB boost. Many older devices just can't chew 2V rms without clipping, but it's their problem. Use a passive divider?..
The vast majority of my library is fine. Only on some recordings is the clipping noise present, and then only in transients. This happens regardless of the output volume control setting in the DAC chip. In other words, even if the speaker output is a mere whisper, the noise can still be heard. The only way I have found to get rid of it is to attenuate the PCM input to the DAC using lower quality volume controls in the player software. I'm using squeezelite on a BBB running Botic/Linux. I want the es9018's output volume via I2C to act as the system's only control. Perhaps squeezelite is part of the problem, perhaps ALSA is part of the problem*, and perhaps others do not have this problem. I'm asking if others have tried programming the es9018 FIR over-sampling filters because I'm looking to add headroom and remove the clipping noise in a way that is least damaging to the sound.
* My ALSA filters do make the problem a touch worse - but I can still hear it with output to hw:0,0.
It should be possible if you set a gain of filter to value smaller than 0.
TFilter - Free online FIR filter design
TFilter - Free online FIR filter design
How do you know it is about clipping in your case? The PCM is a digital signal, which it contain and transport informations about the recorded sounds (taken/processed at the recording stage). Strong (analogue) clipping is a basic technique in the digital world of signals processing. Such analogue clipping it have (it should have) nothing to do, by concept, with the informations inside the digital stream.
Your reported transient clipping like it happen in the analogue domain of your device(s). Such issue is due to artefacts in the informations introduced into or transported by the digital signals, as PCM, DSD, or whatever. There is a alteration of the information which is then converted to analogue in the DAC system. It is very possible that the alteration is introduced at the recording stage, for some (low quality) recordings, by a cheap sound engineering. I think you may look for the cause of the artefacts in your (quite complex) digital processing software, before the D/A converting... Attenuating (analogical or digital), a digital signal as PCM it may alter even more its information content, making inaudible the "clipping", but distorted in different ways the original sound information...
The ESS9018 chip itself it can not produce clipping on its analogue outputs (for by the book use of the chip), unless the system it get somehow wrong bits/informations on its data inputs, noises over the power lines, on its clock signal, and so on. There are for sure in your case, external causes, but not the DAC chip system itself...
Coris, an oversampling if enabled can generate intersample peaks that can be much larger than 0dB:
- https://hydrogenaud.io/index.php/topic,98752.0.html
- https://hydrogenaud.io/index.php/topic,98752.0.html
Thanks Miero! This looks simpler than the Matlab tools I was looking at. I will start on this soon and will report back with results. For the BBB I'll write the I2C programming script in python with the convenient smbus module.
It seems a safe guess because a) the affected recordings require a lot more DAC output attenuation - they are 'loud', and b) when I reduce the 'volume' of the input to the DAC the noise goes away.
I appreciate your thoughts and offer this added background. I'm not dedicated to 'bit-perfect' DAC input, though I try for 'minimal' processing. [Miero's Botic kernel is wonderful in that regard.] My music player is doing DSP signal division to supply 3 Buffalo boards, each with different added corrections. Also, my system has very high resolution drivers, which I enjoy as long as music is mastered well but which make 'scratchy' distortion very obvious.
I remember that Russ White wrote about the Sabre32 FIR filters (a good while back) that there were not enough taps for crossover filtering on the DAC chip. In this particular application I don't need a really perfect noise filter, but one that will combine well with other IIR filters in each channel. So it will be a bit of an adventure!
I imagine that the new ESS DAC chip coming out in the fall will have expanded memory and filter capabilities, so learning by experiments with the es9018 may not be wasted effort even if early results fail to impress.
Looking into the possibility of adding a few dB of headroom to the es9018, I have to learn everything from scratch. Those of you with specific knowledge about the es9018 can probably save me some time, if you would be so kind.
We know that the es9018 has two built-in FIR filters in the OSF stage. Note below the specs and traces from the data sheet. The slow roll-off filter, which sounds nice in my system, looks like the simpler of the two functions. The fast roll-off profile almost looks like a second low-pass filter was added to the result of the slow roll-off function. Is that impression correct? If so, then perhaps my best approach is to a) learn which of the two built-in filters results in the slow roll-off response and continue using it, then b) add a gentle high-pass function to the other filter block.
...and just confirming: the filter's operating frequency should be 64*fs, which would be 2.8224 MHz for 44.1kHz I2S?
Can anybody comment on this and/or add helpful information?
Many thanks in advance!
Frank
We know that the es9018 has two built-in FIR filters in the OSF stage. Note below the specs and traces from the data sheet. The slow roll-off filter, which sounds nice in my system, looks like the simpler of the two functions. The fast roll-off profile almost looks like a second low-pass filter was added to the result of the slow roll-off function. Is that impression correct? If so, then perhaps my best approach is to a) learn which of the two built-in filters results in the slow roll-off response and continue using it, then b) add a gentle high-pass function to the other filter block.
...and just confirming: the filter's operating frequency should be 64*fs, which would be 2.8224 MHz for 44.1kHz I2S?
Can anybody comment on this and/or add helpful information?
Many thanks in advance!
Frank
Attachments
Please help.
I'm finalizing my firmware now, and have encountered a strange problem: the DPLL Number (32-bit value specified in the datasheet) reads quite weird and does not have any reliable divider with the actual SR. The prob is MAY be in the fact that I use 2 oscillators, 49.152 and 45.158MHz depending on the incoming FS. (For spdif I use only the second xtal). The prob may be in the way I'm reading the registers: one read per register, not 4-byte request.
Anybody encountered this???? Maybe I should use SPDIF Status reg (48 + 3)? But I'm unsure that it works for i2s and DSD.
Thank you!
I'm finalizing my firmware now, and have encountered a strange problem: the DPLL Number (32-bit value specified in the datasheet) reads quite weird and does not have any reliable divider with the actual SR. The prob is MAY be in the fact that I use 2 oscillators, 49.152 and 45.158MHz depending on the incoming FS. (For spdif I use only the second xtal). The prob may be in the way I'm reading the registers: one read per register, not 4-byte request.
Anybody encountered this???? Maybe I should use SPDIF Status reg (48 + 3)? But I'm unsure that it works for i2s and DSD.
Thank you!