Most ESS dac boards (even the ones in your pictures) use MCU to set DAC and SRC registers via I2C. SRC alone does not solve your issue unless you can configure it using pin headers (i.e. jumpers).i am learning about SRC to fix this problem, do you have any suggestion on this?
my i2s source is raspberry volumio/rune/moode it will be very difficult to implement i2c. I also tried Hifiduino code on es9018k2m but it doesn't work@tru09x : what is your I2S source? Either provide a way to configure your DAC registers (a 2USD arduino with a trivial code would do), or use the DAC default I2S format in your I2S source.
I'm sure using SRC will fix it, for example using ak4137 input auto detect PCM/DSD output set to i2s32bit or dsd128 it should work in all cases without error. After many days of research, I found out that CT7302CL SRC is common to all 3 circuits above, according to my survey it receives auto detect input PCM / DSD output PCM32bit / DSD.so all i2s data is converted to 32bit and DSD DOP is converted to DSDMost ESS dac boards (even the ones in your pictures) use MCU to set DAC and SRC registers via I2C. SRC alone does not solve your issue unless you can configure it using pin headers (i.e. jumpers).
Last edited:
Does your RPi stack change I2S format according to the input track? I doubt it since it requires changing the I2S kernel module parameters (via DTS), i.e. the module would have to be reloaded between tracks. IMO your I2S format is 64bit fixed (2 x 32). Why do you need auto-detection for 2x16bit I2S?my i2s source is raspberry volumio/rune/moode it will be very difficult to implement i2c. I also tried Hifiduino code on es9018k2m but it doesn't work
As I said SRC alone won't fix it. CT7302CL needs to be configured with I2C. AK4137 can be configured in parallel mode ("HW" mode) but most existing boards use I2C. So most probably you need a MCU as well.I'm sure using SRC will fix it, for example using ak4137 input auto detect PCM/DSD output set to i2s32bit or dsd128 it should work in all cases without error. After many days of research, I found out that CT7302CL SRC is common to all 3 circuits above, according to my survey it receives auto detect input PCM / DSD output PCM32bit / DSD.so all i2s data is converted to 32bit and DSD DOP is converted to DSD
As of the I2C control - that's what the ASoC codec drivers are for. Searching for 9038 on github reveals a few repositories for custom boards with that codec https://github.com/search?l=C&q=9038&type=Repositories
E.g. https://github.com/audiophonics/I-Sabre_9038Q2M or https://github.com/VinnyLorrin/ES9038Q2M-Linux_Driver look reasonable. It would be nice if those board vendors submitted a separate ES9038Q2M codec driver to alsa upstream instead of copy/paste/renaming the implementation into their driver repos, but they typically struggle with the software part of their products so no surprise.
E.g. https://github.com/audiophonics/I-Sabre_9038Q2M or https://github.com/VinnyLorrin/ES9038Q2M-Linux_Driver look reasonable. It would be nice if those board vendors submitted a separate ES9038Q2M codec driver to alsa upstream instead of copy/paste/renaming the implementation into their driver repos, but they typically struggle with the software part of their products so no surprise.
you download customized version volumio 2.882 for Aoide DAC IIAs of the I2C control - that's what the ASoC codec drivers are for. Searching for 9038 on github reveals a few repositories for custom boards with that codec https://github.com/search?l=C&q=9038&type=Repositories
E.g. https://github.com/audiophonics/I-Sabre_9038Q2M or https://github.com/VinnyLorrin/ES9038Q2M-Linux_Driver look reasonable. It would be nice if those board vendors submitted a separate ES9038Q2M codec driver to alsa upstream instead of copy/paste/renaming the implementation into their driver repos, but they typically struggle with the software part of their products so no surprise.
in settings select Aoide Dac pro it is i2c driver for es9038q2m. If using chinese es9038q2m board need to remove MCU and connect i2c, driver support Dop dsd, install filter
Those board layouts look like maybe some problems. At least the SRC may make some sense for attenuating RPi GPIO bus jitter. Hopefully the SRC is using a crystal reference. In any case, looks like some EMI/RFI issues could be lurking.
According to you, how should I arrange it?Those board layouts look like maybe some problems. At least the SRC may make some sense for attenuating RPi GPIO bus jitter. Hopefully the SRC is using a crystal reference. In any case, looks like some EMI/RFI issues could be lurking.
RPi is known for radiated and conducted EMI/RFI that gets into dacs doesn't sound very good. May or may not show up as much on an FFT but its certainly audible when its a problem.
Maybe you are familiar with the Iancanada line of products such as FIFO_Pi, Station_Pi, Shield_Pi, etc.? A lot of those things are to deal with the problems in dacs generated by RPi.
See the SRC clock now, so that's good.
Maybe you are familiar with the Iancanada line of products such as FIFO_Pi, Station_Pi, Shield_Pi, etc.? A lot of those things are to deal with the problems in dacs generated by RPi.
See the SRC clock now, so that's good.
the things you said i have tested, it's like reclocking i2s shake reduction i2sRPi is known for radiated and conducted EMI/RFI that gets into dacs doesn't sound very good. May or may not show up as much on an FFT but its certainly audible when its a problem.
Maybe you are familiar with the Iancanada line of products such as FIFO_Pi, Station_Pi, Shield_Pi, etc.? A lot of those things are to deal with the problems in dacs generated by RPi.
See the SRC clock now, so that's good.
Okay. Wondering what tests you like to use for that?
When I tested one of the early Iancanada FIFO_Pi boards, I put the RPi on and GPIO bus extender and moved it a little farther away. The sound immediately improved. IIRC it was sometime after that Ian started making shields and stuff after he was able to reproduce the problem. It turned out there were radiated emissions of EMI/RFI that went right past the galvanic isolation and reclocking.
When I tested one of the early Iancanada FIFO_Pi boards, I put the RPi on and GPIO bus extender and moved it a little farther away. The sound immediately improved. IIRC it was sometime after that Ian started making shields and stuff after he was able to reproduce the problem. It turned out there were radiated emissions of EMI/RFI that went right past the galvanic isolation and reclocking.
This is similar to Shield_Pi I use allo digione as master DAC module as a slave combined with super clean power source for very good sound, recently I have researched on SRC type that can also reduce i2s vibration to better let it run at ASRC modeView attachment 1202286another design master DAC ASRC I published 20 more than 1 year ago
I see. Have an Allo USBridge Sig they sent me for evaluation. I used to do some listening tests for them, and I sort of competed in a friendly way building my own dacs. Don't know what ever happend to Ioan (aka cdsgames) who was their chief designer.
reclocking iancanada uses an external clock to reduce jitter, as the RPI itself has no clock for audio and its clock is very noisy. ASRC and SRC also reduce jitter by using an i2s modified external clock which is probably not as good as reclockingOkay. Wondering what tests you like to use for that?
When I tested one of the early Iancanada FIFO_Pi boards, I put the RPi on and GPIO bus extender and moved it a little farther away. The sound immediately improved. IIRC it was sometime after that Ian started making shields and stuff after he was able to reproduce the problem. It turned out there were radiated emissions of EMI/RFI that went right past the galvanic isolation and reclocking.
- Home
- Source & Line
- Digital Line Level
- ES9038Q2M Board