hi, there,
i'm on volumio 2.599 and es9038q2m hifibunny drivers, 1.07 board, rpi3b.
we have to get the right nco for 100mHz crystal 1.07 board.
GitHub - eslei322/ES9038Q2M-Linux_Driver
the thd compensation would be acceptable now.
cheers
Attachments
Hi eslei,
Nice work!
May I ask if the thd compensation settings you added can accept either hex or decimal number formats, or only one or the other?
cheers
Late to the party: in post 3524 of last januari is referred to Dropbox for instruction of the output stage.
ES9038Q2M Board
In Dropbox next to the schematic a file ‘OSB.rtf’ can be seen. It looks like a Word-file, but it does not allow me to be opened. What do I miss?
ES9038Q2M Board
In Dropbox next to the schematic a file ‘OSB.rtf’ can be seen. It looks like a Word-file, but it does not allow me to be opened. What do I miss?
Thank you @eslei for answer.
I have tried to compile with your Github source but results are same as with VinnyLorrin code.
In fact there is big difference with declaration (inside hifibunny code) of snd drivers and structure after 4.17 kernel and in my case Volumio 2.599 with kernel 4.19.60 fires many error during compile.
Did you successfully compiled them on kernel 4.19.60?
I have tried to compile with your Github source but results are same as with VinnyLorrin code.
In fact there is big difference with declaration (inside hifibunny code) of snd drivers and structure after 4.17 kernel and in my case Volumio 2.599 with kernel 4.19.60 fires many error during compile.
Did you successfully compiled them on kernel 4.19.60?
It was created in Word-Pad, IIRC, and is in Rich_Text format. Most computers have a program that can open such a file. Did you download and unzip the archive folder first, sometimes skipping that can cause problems. Or, perhaps you are getting an error message of some kind?
hi there,
i'm ok on kernel 4.19.60, cohld you post your detailed compiling see if i can help.
vinnylorrin code is for 49.152mhz, pls reade his readme.md. you will play on fast speed.
cheers
Last edited:
It was created in Word-Pad, IIRC, and is in Rich_Text format. Most computers have a program that can open such a file. Did you download and unzip the archive folder first, sometimes skipping that can cause problems. Or, perhaps you are getting an error message of some kind?
Thanks. I now used Firefox and was able to download and unzip.
Thanks. I now used Firefox and was able to download and unzip.
Your table header shows NCO-3 for two different columns.
Also, what do the green apostrophes indicate?
@eslei,
Your driver is meant to drive ES9038Q2M from RPI. Am I right?
As Mark had good results with an additional Ak4137 stage, I was thinking of using this SRC as well in this chain : RPI -> Ak4137 -> ES9038Q2M.
I'm not a sw guy, but I can code some low level firmware, and have access to logic analyzer to debug control protocols, but I am sure that this kind of hw config would require a specific driver, that could control the ak4137 as well.
What is your opinion, would it be a big problem implementing this kind of hw config in your driver? What would be the biggest challenge?
Im not asking you for implementing this, just it would be good to hear your opinion.
Regards
Attila
Your driver is meant to drive ES9038Q2M from RPI. Am I right?
As Mark had good results with an additional Ak4137 stage, I was thinking of using this SRC as well in this chain : RPI -> Ak4137 -> ES9038Q2M.
I'm not a sw guy, but I can code some low level firmware, and have access to logic analyzer to debug control protocols, but I am sure that this kind of hw config would require a specific driver, that could control the ak4137 as well.
What is your opinion, would it be a big problem implementing this kind of hw config in your driver? What would be the biggest challenge?
Im not asking you for implementing this, just it would be good to hear your opinion.
Regards
Attila
Kay,
There can only be one I2C master at a time. RPi would have to become the I2C master to use eslei's software. The dac board MCU isn't expecting another master so they will both try to control the I2C bus at the same time which can't work properly. The only choice would be to disconnect or disable the dac board MCU somehow. Usually, that means lifting or cutting the I2C pins unless the firmware on your board stops MCU activity with J1, J2 both installed.
There can only be one I2C master at a time. RPi would have to become the I2C master to use eslei's software. The dac board MCU isn't expecting another master so they will both try to control the I2C bus at the same time which can't work properly. The only choice would be to disconnect or disable the dac board MCU somehow. Usually, that means lifting or cutting the I2C pins unless the firmware on your board stops MCU activity with J1, J2 both installed.
Attila,
There is a version of AK4137 board that is made to attach to RPi GPIO bus, and that particular AK4137 board is very low cost. It can be configured with jumpers, so no need to have RPi program it.
However IIUC what eslei is doing, his ES9038Q2M driver operates the dac chip in master mode (I2S bus master), meaning that the dac chip generates all the audio clocks and RPi only controls the I2S DATA signal. In that case, using AK4137 in that mode would be problematic since the dac chip I2S clocks would only make it as far as the AK4137 output clock lines, and not all the way to RPi. In addition, most AK4137 board firmware doesn't support operating AK4137 as an I2S slave, and even for the one board that does support that it is seldom used because AK4137 doesn't sound very good as an I2S slave, it really needs to sync its output to its local crystal clock.
Partly because AK4137 sounds much better with the output synced to a clock, it turns out that jitter can only be minimized when used with Sabre dacs if AK4137 click is synchronous with the dac master clock. I used a clock divider board to divide the dac 100MHz clock by 4 to result in a 25MHz clock signal to run AK4137. That sounded best by far at a very particular clock phase between ES9038Q2M and AK4137. 150ps of clock phase offset between the two chips could make the difference between the best sound and rather mediocre sound. Since that is rather complicated to setup, and not all that low-cost either, I would probably not recommend doing it for now. I was hoping to get back to working on finding a simpler solution, but haven't had time. That said, I kind of suspect that there may be some incorrect timing between data and clocks coming out of AK4137. They are supposed to be out of phase with each other so that the data has time to stabilize at a high or low logic level, at which time a clock edge can trigger the dac to read in the stable data. If that timing sequence is off that could cause problems. I was thinking of delaying AK4137 output clocks a little to see if that allows data to be read more reliably. First though, I would want to study the waveforms with a scope to see if that theory makes sense or not.
Last edited:
Now that the AK4137 is mentioned again: I have the simple version, aimed for use as a HAT on an RPi. I would like to use it between an Amanero (I2S out) and the I2S in of an ES9038q2m board (I have version 1.04). This requires a separate +5V supply (to be inserted via the GPIO bus).
Question 1: is it correct that this will work, without further conditions?
On this simply version the jumpers K1-10 allow for various settings, which can be wired by switches.
Question 2: is it correct that on this simple version you have to (re)set manually each time a different file-type is played?
Question 3: if the board requires manual setting indeed, it there an alternative these days using a control for automatic setting?
Question 1: is it correct that this will work, without further conditions?
On this simply version the jumpers K1-10 allow for various settings, which can be wired by switches.
Question 2: is it correct that on this simple version you have to (re)set manually each time a different file-type is played?
Question 3: if the board requires manual setting indeed, it there an alternative these days using a control for automatic setting?
The AK4137 board needs power for the onboard regulators. Probably better to use clean 5v from somewhere rather than dirty RPi power, but it should work if RPi can supply enough current via GPIO bus.
So far as I know, yes. AK4137 doesn't know incoming sample rate and bit depth, although the latter may not be an issue if using Philips I2S or Left Justified PCM. Sample rate and DSD_ON status is normally needed, if using a USB board instead or RPi then the USB board should have pins to supply that information. Don't know how one would get it from RPi unless perhaps it sends it out on I2C bus or can be configured to do so. If on I2C bus, then an Arduino or similar could read that and set AK4137 jumper pin logic as accordingly.
Don't know. Only can suggest as per answer #2.
I intend to use this particular board. However, as you mentioned, the board shall be operated in Master mode, and synced to ES9038Q2M clock, therefore probably the onboard options are not adequate. Therefore I intend to patch this, and disable all "on-board" controller, and do the programming by the RPI.
That's my plan as well.
I intend to create a small clock generator board based on Silabs Si5340 chip, and distribute two outputs between the AK4137 and the ES9038Q2M. The clock generator chip is capable of handling a programmable skew between the outputs with fine resolution (0.28ps), and in a quite broad range (up to 9.14ns).
So, it shall be a good platform for experimenting.