Seems like it could be plausible for some of their dacs. For Chord Dave it seems unlikely. No way to get -300dB filter response Rob Watts claims with less than 64-bit processing (which would be quadruple precision for Artix-7, probably not very effecient for it), and using million tap filters seems like asking too much from Artix-7 FPGAs unless there are lots of them with very high speed interconnects. Then again, I don't know for a fact what is in Dave, just taking a guess.
Thanks for the answer, sounds good
.Something I dont understand. Why does the ES9038Q2M needs a special driver. I thought the I2S signal (BCK, LRCK, GND and DATA) is a standard. Does the ES9038Q2M needs configuration signals?
I agree about intersample over distortion, and that the 9038Q2M volume does not avoid it. I felt like the main volume control in windows compared to software is slightly different sounding, this is reason for wanting to bypass it, but if it uses 32bit floating point processing a few dB of attenuation shouldnt make a difference .
the HP amp I used also as sort of analysis tool was 8 unity gain opa1622 in parallel per channel, the only thing in the signal path was 1 ohm load sharing resistors.
no measurements but as a benchmark it absolutely kills the O2 amplifier in terms of transparency and sounds a lot nicer too.
Thanks for the answer, sounds good
Something I dont understand. Why does the ES9038Q2M needs a special driver. I thought the I2S signal (BCK, LRCK, GND and DATA) is a standard. Does the ES9038Q2M needs configuration signals?
Yes. The dac chip includes a hardware volume control which should be used instead of software. The instructions that came with the driver somewhere included hooking up I2C between RPI and the dac board. However, that may not be required if you don't want RPi to be able to control the hardware volume level or perhaps other things. Seems to me occip provided a hook up diagram at some point and there is other information in the thread about how to hook up I2C bus to an external controller if desired.
ESS info on hardware volume control: http://www.esstech.com/files/3014/4095/4308/digital-vs-analog-volume-control.pdf
Thanks Mark,
so far I understood that.
I just browsed ebay and found different boards:
1. ES9038 Q2M I2S DSD Optical Coaxial Decoder DAC Headphone Output Audio Amplifier | eBay
2. ES9038 ES9038Q2M DAC Decoder board Support IIS DSD 384KHz NEW V1.07 HIFI AUDIO | eBay
These are board versions V1.06 and V1.07.
What is the difference of these boards, if you know that?
Furthermore I found these boards:
3. ES9038 ES9038Q2M DAC Decoder Board Support IIS DSD 384KHz HIFI Newest Version | eBay
4.Assembled ES9038 Q2M I2S DSD Optical + Coax Input Decoder Board / DAC L9-48 | eBay
Board 3 looks similar to the first 2 boards, but has switches onboard.
The 4.th board is totally different, but looks not bad.
Does it make sense to by on of these boards?
so far I understood that.
I just browsed ebay and found different boards:
1. ES9038 Q2M I2S DSD Optical Coaxial Decoder DAC Headphone Output Audio Amplifier | eBay
2. ES9038 ES9038Q2M DAC Decoder board Support IIS DSD 384KHz NEW V1.07 HIFI AUDIO | eBay
These are board versions V1.06 and V1.07.
What is the difference of these boards, if you know that?
Furthermore I found these boards:
3. ES9038 ES9038Q2M DAC Decoder Board Support IIS DSD 384KHz HIFI Newest Version | eBay
4.Assembled ES9038 Q2M I2S DSD Optical + Coax Input Decoder Board / DAC L9-48 | eBay
Board 3 looks similar to the first 2 boards, but has switches onboard.
The 4.th board is totally different, but looks not bad.
Does it make sense to by on of these boards?
Ampi,
#1 and #2 look about the same except one appears to be offering to include an Apple remote in the deal. They are both 1.07 which has little bit revised hardware layout and the latest firmware that is easy to use with another I2S controller.
#3 is usable, but probably doesn't have a firmware feature that can stop the board MCU from accessing the I2S bus. Therefore, hooking up an external I2S master is still possible, but it would involve some tiny soldering and wiring work that some people consider too risky to attempt.
#4 is junk to my way of thinking. Suggest avoiding that one.
#1 and #2 look about the same except one appears to be offering to include an Apple remote in the deal. They are both 1.07 which has little bit revised hardware layout and the latest firmware that is easy to use with another I2S controller.
#3 is usable, but probably doesn't have a firmware feature that can stop the board MCU from accessing the I2S bus. Therefore, hooking up an external I2S master is still possible, but it would involve some tiny soldering and wiring work that some people consider too risky to attempt.
#4 is junk to my way of thinking. Suggest avoiding that one.
The million+ tap Hugo M has an Artix7 A200T. The DAVE has to make do with a Spartan6 LX75
Okay, thank you for the info. The Spartan6 LX75 is an older design. Arix-7 is a newer generation and A200T is a powerful one. Names like Artix-7 are defined by certain features, with the higher grades like A200T referring to how many slices, arithmetic units, block memories, etc., for that version of Artix-7. Between something like Spartan-7 and Artix-7, the 7 means they are a later generation technology that series 6 devices. The name Spartan refers to a line of chips with certain features and capabilities in things like the arithmetic slices. Artix is the next line up from Spartan, and Artix arithmetic slices have more powerful features than Spartan devices, as one example of differences between lines. Then there is something else not given in the name, but that is in the part numbers. The chips come in different speed-grades where the higher-speed grades run faster internally. Sometimes up around 500MHz to 600MHz. So, for something like a top of the line Kintex (which is above Artix) with the most slices, and in the fastest speed grade, they can be immensely powerful parallel processors, and they get very expensive if one wants the best of everything. Only devices above the Artix line natively support 64-bit processing. Both Spartan and Artix are by default 16-bit or 18-bit devices with accumulators big enough for sums and products. However, they have native support to tying two slices together for 32-bit processing. One could wire together more slices to get higher bit-depths, but so far as I know one would have to do a lot more work to make it happen (unless maybe there is paid software that can do it). Since Rob Watts claimed fitlers with 300dB of attenuation, if that's really true, that would require more than 32-bits to represent, so I don't know how he would be doing it. I do know if one can afford to spend several 10's of thousands of dollars for licences there are a lot of tools to make complex designs much easier to implement and optimize. Of course, there are also maintenance licences to pay for evey year too. Probably doesn't cost more than hiring an expert DSP engineer though, so in that sense it could seem quite reasonable.
Last edited:
Thanks for your opinion.
I'am still thinking about combining the ES9038 board with
the resampler
Raspi + AK4137 Digital Network Player I2S 32bit 384K FOR Raspberry Pi 3B 2B 3b+ | eBay
or with the Reclocker
Kali (i2s Reclocker)
So far I know, the AK4137 board upsamples the input signal to a higher frequency which can be choosen by the jumper and
the Kali uses the same frequency but better quality and has a signal buffer.
Does it make sense to use one of these boards?
These 2 boards also deliver MCLK signal. I'am not able to find an MCLK input port on the ES9038QM boards. Do you know were I can find this input?
Ampi,
I don't like that particular AK4137 board. I don't see a list of what all 'K' jumpers do, except for K10. So, I don't understand how one could use all the features of AK4137 in that case. The other 2 common kinds of AK4137 boards are a little bit different in how they can be configured, but at least most of the possible settings are available.
Regarding Kali, it has a reputation as a good reclocker, but I have never used one or read the manual to see what it can do. So, hard to say. Probably you could use it if you think what it does is what you want. If you want an AK4137, I would recommend using one of the ones we have recommended in this thread. They only input signals they need are the normal I2S ones: DATA, BCLK, LRCK, and ground. I'm sure they could be patched to from the connector on an RPi board to AK4137 board input pins so long as the wire lengths are kept as short as possible and good quality connectors are used. If you wanted to try one of the other AK4137 boards, it might be a good idea to try that first and then see if you still think you need a Kali (as an effort to further reduce jitter).
I don't like that particular AK4137 board. I don't see a list of what all 'K' jumpers do, except for K10. So, I don't understand how one could use all the features of AK4137 in that case. The other 2 common kinds of AK4137 boards are a little bit different in how they can be configured, but at least most of the possible settings are available.
Regarding Kali, it has a reputation as a good reclocker, but I have never used one or read the manual to see what it can do. So, hard to say. Probably you could use it if you think what it does is what you want. If you want an AK4137, I would recommend using one of the ones we have recommended in this thread. They only input signals they need are the normal I2S ones: DATA, BCLK, LRCK, and ground. I'm sure they could be patched to from the connector on an RPi board to AK4137 board input pins so long as the wire lengths are kept as short as possible and good quality connectors are used. If you wanted to try one of the other AK4137 boards, it might be a good idea to try that first and then see if you still think you need a Kali (as an effort to further reduce jitter).
Ongoing FPGA discussion
Been working on the computer that will be used for FPGA programming. Things are coming along with that reasonably well. Also, collecting more documentation to read. Lots of it. The more I think about it, the initial upsampling done for DAC-3 is in the hardware SRC4392 chip. It uses a rather sophisticated polyphase technique for which some patents still seem to be in effect. One issue I am mulling over is that first bit of upsampling done by SRC4392 that doesn't seem to leave an unfavorable imprint on the sound from its filtering, and that is used to give the later interpolation filter in Spartan 6 some more transition band frequency space in which to work for its further upsampling and filtering. Still thinking about the best way if we wanted to do all the upsampling in FPGA, and maybe even build a DSD modulator into it eventually. Don't want to scare anyone away, I'm just starting to think about some more stuff. No doubt it will take some time before it clicks, but at least it usually does click eventually.
Anyone else doing anything to make some progress towards possible FPGA development? Doesn't have to be anything much, just checking in with those having expressed some interest so far.
Been working on the computer that will be used for FPGA programming. Things are coming along with that reasonably well. Also, collecting more documentation to read. Lots of it. The more I think about it, the initial upsampling done for DAC-3 is in the hardware SRC4392 chip. It uses a rather sophisticated polyphase technique for which some patents still seem to be in effect. One issue I am mulling over is that first bit of upsampling done by SRC4392 that doesn't seem to leave an unfavorable imprint on the sound from its filtering, and that is used to give the later interpolation filter in Spartan 6 some more transition band frequency space in which to work for its further upsampling and filtering. Still thinking about the best way if we wanted to do all the upsampling in FPGA, and maybe even build a DSD modulator into it eventually. Don't want to scare anyone away, I'm just starting to think about some more stuff. No doubt it will take some time before it clicks, but at least it usually does click eventually.
Anyone else doing anything to make some progress towards possible FPGA development? Doesn't have to be anything much, just checking in with those having expressed some interest so far.
Last edited:
I was always under the impression that DAC3 used the SRC4392 solely for up sampling to 211kHz and of course for jitter reduction.
I'm guessing they just run the Sabre DAC in synchronous mode.
There are two separate issues here. One is the up sampling and filter response but the second is the asynchronous operation and with it, inherent jitter rejection.
Does the DAC3 sound good because the SRC4392 has a nice sounding digital
filter response, very good jitter rejection or both?
FWIW, looking at data sheet, the SRC4392 looks to have half band filter response so there is some aliasing.
Are you intending to implement a synchronous upsampling filter or a full ASRC?
Right. So they are disabling Sabres internal filters.
T
Would it possibly make things faster/easier or even possible if we were to design the system in Mathlab Simulink and then use the Xilinx System Generator for DSP to generate the FPGA code?
Mathlab also seems to have a number of libraries for sound processing, etc that could be useful.
wealas, In fact I am planning to take a look at it. However, it is important to make sure the versions Vivado and Matlab are compatible. In addition, it is still necessary to learn how to use Vivado, not just Matlab. The way it works is that Simulink and Matlab can generate VHDL that Vivado can then compile into design that can be simulated and perhaps be workable. It may also be necessary to define Vivado constraints for the project, etc. Nonetheless, Matlab and Simulink could make FPGA design much easier than without them. Of course, there are other tools too, but the combination we are discussing is a popular one.
Terry,
DAC-3 is not a synchronous design. Everything runs on its own clock. SRC4392 runs on a 27MHz clock, and it looks like the dac chip runs on a 50MHz clock. That is presumably the case because DAC-3 is designed to work primarily with SPDIF, TOSLINK, and AES inputs. USB seems like almost an add-on, rather than the primary focus. Thus SRC4392 is SPDIF receiver, jitter attenuator, and first stage upsampler to 211kHz. It is stage at which a little extra frequency space (or where increased separation between input sample rate digital images is produced). The subsequent stage of interpolation filtering in FPGA then takes advantage of the image separation created in SRC4392. The FPGA interpolation filter uses the increased spacing between digital images to allow for a more relaxed transition band than would otherwise be possible. The FPGA also takes care of the dac volume control, which according to certain things said by Benchmark, appears to feed some of the dac channels in or out of phase and with some minimal digital attenuation of only some channels. The dac outputs are mixed together in the analog domain. The technique solves the problem of how to implement high resolution digital volume control without having access to the way the it would be implemented inside the dac (built-in digital volume control doesn't work if using external interpolation filtering). The problem has to do with avoiding loss of resolution when attenuating I2S integer audio data, since bits will unavoidably be lost. Clever solution. Also, jitter is attenuated a lot by all the upsampling, so although dac chip ASRC is still enabled, it sure sounds like DPLL bandwidth is probably set to a low number for improved sound quality.
DAC-3 is not a synchronous design. Everything runs on its own clock. SRC4392 runs on a 27MHz clock, and it looks like the dac chip runs on a 50MHz clock. That is presumably the case because DAC-3 is designed to work primarily with SPDIF, TOSLINK, and AES inputs. USB seems like almost an add-on, rather than the primary focus. Thus SRC4392 is SPDIF receiver, jitter attenuator, and first stage upsampler to 211kHz. It is stage at which a little extra frequency space (or where increased separation between input sample rate digital images is produced). The subsequent stage of interpolation filtering in FPGA then takes advantage of the image separation created in SRC4392. The FPGA interpolation filter uses the increased spacing between digital images to allow for a more relaxed transition band than would otherwise be possible. The FPGA also takes care of the dac volume control, which according to certain things said by Benchmark, appears to feed some of the dac channels in or out of phase and with some minimal digital attenuation of only some channels. The dac outputs are mixed together in the analog domain. The technique solves the problem of how to implement high resolution digital volume control without having access to the way the it would be implemented inside the dac (built-in digital volume control doesn't work if using external interpolation filtering). The problem has to do with avoiding loss of resolution when attenuating I2S integer audio data, since bits will unavoidably be lost. Clever solution. Also, jitter is attenuated a lot by all the upsampling, so although dac chip ASRC is still enabled, it sure sounds like DPLL bandwidth is probably set to a low number for improved sound quality.
Last edited:
Latest Vivado Design Suite supports Mathlab and Simulink R2017a, R2017b, and R2018a. As far as I can tell this is valid for the WebPack as well.
Agreed, we'll need to learn Vivado but hopefully not be experts in writing and optimizing algorithms in C/C++.
Wealas,
Yes, I know. I'm starting with Vivado 2017.4 since the Artsy S7 I2S demo works with that. Happens that I already have some experience with C/C++ although no expert. Have to learn some VHDL and maybe Verilog, which I am starting to do.
From what you are finding out, it sounds like you are forging ahead which is great. If you could manage to lay your hands on an evaluation board like the Artsy S7 or perhaps something else of your choice, you might be the first person to make a diy interpolation filter for Sabre dacs. If so, good for you.
Yes, I know. I'm starting with Vivado 2017.4 since the Artsy S7 I2S demo works with that. Happens that I already have some experience with C/C++ although no expert. Have to learn some VHDL and maybe Verilog, which I am starting to do.
From what you are finding out, it sounds like you are forging ahead which is great. If you could manage to lay your hands on an evaluation board like the Artsy S7 or perhaps something else of your choice, you might be the first person to make a diy interpolation filter for Sabre dacs. If so, good for you.
...sorry ..i want to inform you...
this ready DAC is not fine...looks good for modding but its not working at all...https://www.diyaudio.com/forums/dig...3-cheap-board-modification-7.html#post5737769
chris
this ready DAC is not fine...looks good for modding but its not working at all...https://www.diyaudio.com/forums/dig...3-cheap-board-modification-7.html#post5737769
chris
chris,
Did you try sending an message to the seller asking for a link to download the Windows driver? Often they can do that if you ask.
Also, from the picture it looks like it has an XMOS USB board, not CM6631A. Regarding the prospect of modding it, don't know how much we might be able to help you with that. You will probably need to sketch out the schematic which can be easier if you have a DVM with a continuity test mode that beeps (so you don't have to look), and if you write down the part numbers of all the chips on it and download the data sheets. Because some people have never done all that before, we always recommend to mod the boards most commonly used in this thread.
Mark
Did you try sending an message to the seller asking for a link to download the Windows driver? Often they can do that if you ask.
Also, from the picture it looks like it has an XMOS USB board, not CM6631A. Regarding the prospect of modding it, don't know how much we might be able to help you with that. You will probably need to sketch out the schematic which can be easier if you have a DVM with a continuity test mode that beeps (so you don't have to look), and if you write down the part numbers of all the chips on it and download the data sheets. Because some people have never done all that before, we always recommend to mod the boards most commonly used in this thread.
Mark
Last edited: