The Vref dividers for each channel should draw some current whenever voltage is applied.
When I measure AVCCR to ground I get 172ohm without anything else connected to that pin. AVCCL gets 3.3V from the other battery, rest of the dac is not getting any voltage. Perhaps It's just a weird result of the rest of the dac not beeing powered. When I tested it earlier the dac played fine atleast.
I see these are used a lot by people, usually in SQ sensitive areas, but there is basically no info or discussion on them at diyaudio, what the pros/cons are, what the differences compared to other battery types.
Do know where their popularity stems from?
LiFePO4 Batteries
Hi laserscrape! The LiFePO4 batteries have been around for about a decade. It is just another type of lithium batteries, with a bit less volumetric efficiency. They are easier to handle, and provide about 2000 full charge/discharge cycles, as compared to about 500 cycles on your cellphone Lithium battery. You will find tons of literature on the web.
Hi laserscrape! The LiFePO4 batteries have been around for about a decade. It is just another type of lithium batteries, with a bit less volumetric efficiency. They are easier to handle, and provide about 2000 full charge/discharge cycles, as compared to about 500 cycles on your cellphone Lithium battery. You will find tons of literature on the web.
I would not recommend that option. The low-value resistors around the differential summing stage were designed for low noise above all else, even at the expense of distortion (IMHO). Also, it was designed for differential summing to be done by OPA1622, a headphone amp opamp, the wrong tool for the job (again, IMHO). Putting that opamp on an 8-pin dip adapter can't work right since the ground pin needs to be connected to actual ground or distortion goes up. There are other issues too. Both Vref signals are tied together, etc, etc. Might be one could use the bare PCB with other parts, that would be as close as I would consider.
Besides, I keep trying to explain to people that its best for the output stage to be on the same ground plane as the dac chip, as per ESS advice. It also helps to have it exactly were I suggested to put it as it can alleviate the RF heating and distortion issues that can occur in the opamps otherwise (as happens with the board you were thinking of using when used as part of the RPi stack design).
My apologies to anyone I may have offended by speaking so frankly, but I feel that I have obligated myself over time to give my best personal advice about ES9038Q2M dac modding in this thread.
Last edited:
sync mode using AK4137 / JLsounds ?
Mark,
would you please advise If Is possible to use AK4137 board that have spdif, optical, I2S Inputs Lusya AK4137 DAC SRC Audio 384K 32Bit DSD256 DSD IIS conversion for hifi amplifier With remote control-in Digital-to-Analog Converter from Consumer Electronics on AliExpress to cooperate with Smp cb 1.07 pcb In order to get synchronous mode of es9038q2m dac
I can not see crystals on new AK4137 pcb
same question about Jlsounds I2S over usb pcb
Mark,
would you please advise If Is possible to use AK4137 board that have spdif, optical, I2S Inputs Lusya AK4137 DAC SRC Audio 384K 32Bit DSD256 DSD IIS conversion for hifi amplifier With remote control-in Digital-to-Analog Converter from Consumer Electronics on AliExpress to cooperate with Smp cb 1.07 pcb In order to get synchronous mode of es9038q2m dac
I can not see crystals on new AK4137 pcb
same question about Jlsounds I2S over usb pcb
Solmoloko,
The clocks are there on the AK4137 board, they are just very small size ones.
However, using AK4137 with ES9038Q2M in synchronous mode is somewhat complicated.
You might have better luck getting I2SoverUSB to work with ES9038Q2M in synchronous mode, but still much easier said than done.
To run the dac and whatever feeds I2S to the dac synchronously means that the dac clock needs to be twice the bit clock rate if the I2S audio, and the I2S must be in 32-bit format.
That means you couldn't easily keep the 100MHz dac clock we use with the Chinese ES9038Q2M boards.
Also, there is the matter of ES9038Q2M being very picky about the quality of clock and I2S signals in order to run in synchronous mode. Running wires around between boards is almost sure to mess up the square waves, even if they were very nice and square to begin with. The signals could be reclocked (or relatched, same thing) in a D-flip flop chip or in cascaded D-flip flops. That's one of the things Iancanada does in FIFO_Pi, for example, to make the waveforms have fast rise-times.
We could talk more about if you are up for some R&D yourself.
The clocks are there on the AK4137 board, they are just very small size ones.
However, using AK4137 with ES9038Q2M in synchronous mode is somewhat complicated.
You might have better luck getting I2SoverUSB to work with ES9038Q2M in synchronous mode, but still much easier said than done.
To run the dac and whatever feeds I2S to the dac synchronously means that the dac clock needs to be twice the bit clock rate if the I2S audio, and the I2S must be in 32-bit format.
That means you couldn't easily keep the 100MHz dac clock we use with the Chinese ES9038Q2M boards.
Also, there is the matter of ES9038Q2M being very picky about the quality of clock and I2S signals in order to run in synchronous mode. Running wires around between boards is almost sure to mess up the square waves, even if they were very nice and square to begin with. The signals could be reclocked (or relatched, same thing) in a D-flip flop chip or in cascaded D-flip flops. That's one of the things Iancanada does in FIFO_Pi, for example, to make the waveforms have fast rise-times.
We could talk more about if you are up for some R&D yourself.
samoloko,
Basically there are required clock frequencies for different modes of operation. There are also different data clock frequencies for PCM or DSD over an I2S interface.
Data clock for PCM = 2-channels * bits_per_data_word * sample_rate
in the above * means multiplication. For 32-bit words (native for Sabre dacs), since we have two channels we multiply the sample rate (such as 44.1kHz) times 64 to get the bit clock frequency.
For Sabre in synchronous mode, MCLK must be twice the data clock frequency, or an (even?) multiple of that. Also, the word size much be in native format (32-bits).
For asynchronous mode, MCLK must be greater than 3 times the data clock frequency.
For one thing, it means if you design for synchronous mode and it doesn't work, it still may work in asynchronous mode if a lower sample rate is played.
Also, there are two audio clock families, 44kHz and 48kHz. DSD is normally clocked using the 44kHz clock family (except in special cases, such as HQ Player and my 2nd modded dac).
Are you with me so far? If not please let me know.
Moving along then, my second modded dac used 100MHz for MCLK. It is possible to export MCLK from the dac on a GPIO pin, which I did. I then divided the MCLK frequency by 4 to produce a 25Mhz clock signal.
The 25Mhz clock was used to clock AK4137 in DSD256 mode. That gives an unusual DSD256 bit clock frequency of 12.5MHz (but that's okay in this case).
I found that the sound quality of the dac was very sensitive to small changes in the 25Mhz clock phase relative to MCLK. The divider chip allowed me to change that timing in very small steps (125pS or 250pS, don't recall which right now). Sound quality could change quite a bit with just one step.
One might guess that the timing sensitivity was because I did not reclock (relatch) the I2S signals physically right next to the dac chip to make sure they looked very square and lined up in time. (A very high speed scope would be very helpful for verifying the correct operation of such circuitry. You would need at least 100MHz and that's really not enough.)
Reclocking involves using a very fast D-flip flop chip to store the signals for a very short time then clock them out all precisely at the same time. That must be done synchronously with MCLK.
You still with me?
Well, lets stop here for now and give folks a chance to absorb and mull over what has been said so far. Also, let's see if there are any questions up to this point.
Basically there are required clock frequencies for different modes of operation. There are also different data clock frequencies for PCM or DSD over an I2S interface.
Data clock for PCM = 2-channels * bits_per_data_word * sample_rate
in the above * means multiplication. For 32-bit words (native for Sabre dacs), since we have two channels we multiply the sample rate (such as 44.1kHz) times 64 to get the bit clock frequency.
For Sabre in synchronous mode, MCLK must be twice the data clock frequency, or an (even?) multiple of that. Also, the word size much be in native format (32-bits).
For asynchronous mode, MCLK must be greater than 3 times the data clock frequency.
For one thing, it means if you design for synchronous mode and it doesn't work, it still may work in asynchronous mode if a lower sample rate is played.
Also, there are two audio clock families, 44kHz and 48kHz. DSD is normally clocked using the 44kHz clock family (except in special cases, such as HQ Player and my 2nd modded dac).
Are you with me so far? If not please let me know.
Moving along then, my second modded dac used 100MHz for MCLK. It is possible to export MCLK from the dac on a GPIO pin, which I did. I then divided the MCLK frequency by 4 to produce a 25Mhz clock signal.
The 25Mhz clock was used to clock AK4137 in DSD256 mode. That gives an unusual DSD256 bit clock frequency of 12.5MHz (but that's okay in this case).
I found that the sound quality of the dac was very sensitive to small changes in the 25Mhz clock phase relative to MCLK. The divider chip allowed me to change that timing in very small steps (125pS or 250pS, don't recall which right now). Sound quality could change quite a bit with just one step.
One might guess that the timing sensitivity was because I did not reclock (relatch) the I2S signals physically right next to the dac chip to make sure they looked very square and lined up in time. (A very high speed scope would be very helpful for verifying the correct operation of such circuitry. You would need at least 100MHz and that's really not enough.)
Reclocking involves using a very fast D-flip flop chip to store the signals for a very short time then clock them out all precisely at the same time. That must be done synchronously with MCLK.
You still with me?
Well, lets stop here for now and give folks a chance to absorb and mull over what has been said so far. Also, let's see if there are any questions up to this point.
Last edited:
I didn't say one needs a 100MHz clock for sync mode in general. In fact, what I did for my 2nd modded dac is not how sync mode is usually implemented. Just wanted to explain what direct experience I have so far in coming close to sync mode and what else likely would need to be done.
To cut to the chase with I2SoverUSB, it can export 45/49MHz and or 22/24Mhz clocks. If using external clocks with it, it needs 45/49MHz clocks sent to it. Which one it needs depends on a signal it outputs to tell you which clock to send.
In theory you could use its 45/49MHz clocks to provide MCLK. In that case you might be able to play up DSD512 in sync mode. The problem you might encounter is that all the signals coming from I2SoverUSB have to arrive at the dac chip with near perfect fidelity. The I2S signals could be reclocked, but not the MCLK signal. That's because the clock that clocks a D-Flip Flop has to run at least at twice the maximum frequency to be reclocked. Also, a D-flip flop has setup and hold time constraints meaning that the signals to be reclocked have to be in a certain phase range with respect to master clock that is clocking the D-flip flop. Since an MCLK from I2SoverUSB could not be reclocked, it would probably be in rather poor condition and jittery by the time it reached the dac chip. Not good for best sound quality in that case. If you can get an MCLK to the dac chip clock input with great fidelity, nice and square and very low jitter, then fine. Otherwise you would need another approach.
The other approach is to put two clocks right next to the dac chip. They would need to be at standard clock frequencies, such as 45/49MHz or maybe twice that if you want to use Accusilicon clocks available for that. You would then need to buffer the clocks through something like NB3L553 so you can send a copy in near perfect condition to the dac chip, and a separate copy to the external clock input on I2SoverUSB (possibly divided by 2 if using faster clocks for the dac chip). Then when the USB board sends you I2S signals you can reclock them with a very fast (tiny logic or maybe Potato semi parts) D-flip flop clocked by another copy of your selected master clock. Each clock should have its own dedicated voltage regulator. The clock buffer(s) and reclocker might be able to run from another regulator to keep their noise out of the clock supplies. Maybe from another two regulators. Don't know, haven't built the topology myself to see how sensitive devices are to each other's noise on the power rails. Likely the effects of noise on shared power rails would be audible, based on private communications with a dac manufacturer. Therefore I would suggest very conservative design for a prototype. The idea from my perspective would be to see what is the best you can do, then consider scaling back if you decide its okay for future designs, or not if if its not okay in your judgement. Have to see what you get when you try it, right?
Also, don't forget proper bypassing of all active device power pins right at the device, preferably by the shortest possible path to surface ground plane. A ground plane on the other side of a board would not be a good.
For all this to work well, a 4-layer or greater PCB should really be used. I have looked as some different reclocked and local-clock designs, and most are not really designed for best possible performance. Only one dac maker gets it to work the best they really could, at least of the ones I know of. Also know of one reclocker and local master clock design that is rather poor, better performance by skipping the whole thing. Enough said on that. Suggest reading 'Electromagnetic Compatibility Engineering' by Henry Ott.
Another thing I found with my 2nd modded dac project is that it is possible to make an async design that sounds as good or better than a very well implemented sync mode design. Of course, jitter needs to be really low for that, and timing needs to be exactly right, but its possible. Also, DPLL must be strongly stable at 1, the minimum async DPLL bandwidth setting.
Then, we get into the subject of setting up the dac chip to run in sync mode. Depends on the exact chip, but all the register settings that would seem to turn off PLL, ASRC, etc. must be turned off, turn on 128_fs (send 32-bit data words only), and DPLL must be set to 0. If the dac can't get lock with ASRC off (DPLL=0) it will mute. Lock status can be read in one of the last registers.
To cut to the chase with I2SoverUSB, it can export 45/49MHz and or 22/24Mhz clocks. If using external clocks with it, it needs 45/49MHz clocks sent to it. Which one it needs depends on a signal it outputs to tell you which clock to send.
In theory you could use its 45/49MHz clocks to provide MCLK. In that case you might be able to play up DSD512 in sync mode. The problem you might encounter is that all the signals coming from I2SoverUSB have to arrive at the dac chip with near perfect fidelity. The I2S signals could be reclocked, but not the MCLK signal. That's because the clock that clocks a D-Flip Flop has to run at least at twice the maximum frequency to be reclocked. Also, a D-flip flop has setup and hold time constraints meaning that the signals to be reclocked have to be in a certain phase range with respect to master clock that is clocking the D-flip flop. Since an MCLK from I2SoverUSB could not be reclocked, it would probably be in rather poor condition and jittery by the time it reached the dac chip. Not good for best sound quality in that case. If you can get an MCLK to the dac chip clock input with great fidelity, nice and square and very low jitter, then fine. Otherwise you would need another approach.
The other approach is to put two clocks right next to the dac chip. They would need to be at standard clock frequencies, such as 45/49MHz or maybe twice that if you want to use Accusilicon clocks available for that. You would then need to buffer the clocks through something like NB3L553 so you can send a copy in near perfect condition to the dac chip, and a separate copy to the external clock input on I2SoverUSB (possibly divided by 2 if using faster clocks for the dac chip). Then when the USB board sends you I2S signals you can reclock them with a very fast (tiny logic or maybe Potato semi parts) D-flip flop clocked by another copy of your selected master clock. Each clock should have its own dedicated voltage regulator. The clock buffer(s) and reclocker might be able to run from another regulator to keep their noise out of the clock supplies. Maybe from another two regulators. Don't know, haven't built the topology myself to see how sensitive devices are to each other's noise on the power rails. Likely the effects of noise on shared power rails would be audible, based on private communications with a dac manufacturer. Therefore I would suggest very conservative design for a prototype. The idea from my perspective would be to see what is the best you can do, then consider scaling back if you decide its okay for future designs, or not if if its not okay in your judgement. Have to see what you get when you try it, right?
Also, don't forget proper bypassing of all active device power pins right at the device, preferably by the shortest possible path to surface ground plane. A ground plane on the other side of a board would not be a good.
For all this to work well, a 4-layer or greater PCB should really be used. I have looked as some different reclocked and local-clock designs, and most are not really designed for best possible performance. Only one dac maker gets it to work the best they really could, at least of the ones I know of. Also know of one reclocker and local master clock design that is rather poor, better performance by skipping the whole thing. Enough said on that. Suggest reading 'Electromagnetic Compatibility Engineering' by Henry Ott.
Another thing I found with my 2nd modded dac project is that it is possible to make an async design that sounds as good or better than a very well implemented sync mode design. Of course, jitter needs to be really low for that, and timing needs to be exactly right, but its possible. Also, DPLL must be strongly stable at 1, the minimum async DPLL bandwidth setting.
Then, we get into the subject of setting up the dac chip to run in sync mode. Depends on the exact chip, but all the register settings that would seem to turn off PLL, ASRC, etc. must be turned off, turn on 128_fs (send 32-bit data words only), and DPLL must be set to 0. If the dac can't get lock with ASRC off (DPLL=0) it will mute. Lock status can be read in one of the last registers.
Last edited:
Mark,
appreciate very much your knowledge and willing to share
If I get It right to clock synchronously es9038 chip Is not easy case
one way to get It Is true sync mode using Ian Fifo_Pi and dual es9038q2m Hat described IanCanada's Latest RPi GB Goodies Impressions... and your tweaks, mods and hints...
I read that you tried that setup - would you please share your Impression from sound quality
additional question - can we feed Ian fifo_pi with other than rpi source, for example using AK4118 digital Interfaces that sells at around 45 usd AK4118 цифровой приемник доска аудио декодер DAC SPDIF к IIS коаксиальный Оптический USB AES EBU вход поддержка XMOS Amanero 1,3 дюймов OLED-in Цифро-аналоговые преобразователи (ЦАП) from Бытовая электроника on AliExpress
appreciate very much your knowledge and willing to share
If I get It right to clock synchronously es9038 chip Is not easy case
one way to get It Is true sync mode using Ian Fifo_Pi and dual es9038q2m Hat described IanCanada's Latest RPi GB Goodies Impressions... and your tweaks, mods and hints...
I read that you tried that setup - would you please share your Impression from sound quality
additional question - can we feed Ian fifo_pi with other than rpi source, for example using AK4118 digital Interfaces that sells at around 45 usd AK4118 цифровой приемник доска аудио декодер DAC SPDIF к IIS коаксиальный Оптический USB AES EBU вход поддержка XMOS Amanero 1,3 дюймов OLED-in Цифро-аналоговые преобразователи (ЦАП) from Бытовая электроника on AliExpress
Last edited:
FIFO_Pi itself (and Shield Pi, which should be used) are fine. NDK clocks for it are fine.
Ian has Receiver_Pi to accept I2S or SPDIF, etc. No need for AK4118
Things start getting less fine with the Dual ES9038Q2M Hat dac, although if one correctly powers it with 2-LDOs and 1-AVCC opamp buffer supply it can work okay, with the exception that both AVCC channels are tied together on the dac board so stereo separation suffers.
The Output Stage board is less good yet, Ian stopped using his and uses transformers instead, a sign of utter failure in my view. One needs at least proper I/V conversion first. The output stage board never sounded great, it was designed with resistance values that are too low, and for OPA1622 in the differential summing position. Problem is OPA1622 should not be mounted on an 8-pin dip adapter since that leaves the ground pin on the IC unconnected to ground. It works, but distortion is considerably higher than it should be. But, resistor values around the differential summing opamp are too low for lowest distortion out of OPA1612. If parts values were adjusted to what we recommended or the Topping schematic that has been posted, it would have been better. Also, the output stage suffered from distortion caused by RF from the dac board. I was able to make mine a lot better by using a ribbon cable to separate the two with some distance. Also found I had to fold over the ribbon cable a certain way to cancel out most of the distortion. That's why I recommend the output stage location I do in this thread along with running wires to it along the ground plane to get a little capacitance to ground.
I wrote up my findings in a series of posts that were made over several days in one of Ian's threads so anyone could make their dac sound better. Don't think anyone tried what I suggested, since Ian is the leader and the followers tend to do what he suggests. Ian at least came up with the Shield Pi and a filter for the input of the output stage. Most of the people seem to have abandoned the output stage and use voltage mode transformers instead. Expensive transformers too. I don't get it.
Ian has Receiver_Pi to accept I2S or SPDIF, etc. No need for AK4118
Things start getting less fine with the Dual ES9038Q2M Hat dac, although if one correctly powers it with 2-LDOs and 1-AVCC opamp buffer supply it can work okay, with the exception that both AVCC channels are tied together on the dac board so stereo separation suffers.
The Output Stage board is less good yet, Ian stopped using his and uses transformers instead, a sign of utter failure in my view. One needs at least proper I/V conversion first. The output stage board never sounded great, it was designed with resistance values that are too low, and for OPA1622 in the differential summing position. Problem is OPA1622 should not be mounted on an 8-pin dip adapter since that leaves the ground pin on the IC unconnected to ground. It works, but distortion is considerably higher than it should be. But, resistor values around the differential summing opamp are too low for lowest distortion out of OPA1612. If parts values were adjusted to what we recommended or the Topping schematic that has been posted, it would have been better. Also, the output stage suffered from distortion caused by RF from the dac board. I was able to make mine a lot better by using a ribbon cable to separate the two with some distance. Also found I had to fold over the ribbon cable a certain way to cancel out most of the distortion. That's why I recommend the output stage location I do in this thread along with running wires to it along the ground plane to get a little capacitance to ground.
I wrote up my findings in a series of posts that were made over several days in one of Ian's threads so anyone could make their dac sound better. Don't think anyone tried what I suggested, since Ian is the leader and the followers tend to do what he suggests. Ian at least came up with the Shield Pi and a filter for the input of the output stage. Most of the people seem to have abandoned the output stage and use voltage mode transformers instead. Expensive transformers too. I don't get it.
Last edited: