Yes, at the headphone end. Its a step up from the 2 pin connectors on many IEMs. Its not something I found myself connecting and disconnecting all the time and what mattered was the ergonomics and robustness of connection under physical load with the cable moving around. also not terribly difficult to solder either.
My apologies if my reply the other day came across as short. Wasnt my intention.
Those Assist tools is made for straight connections
so for edged some modifications are required. But still not a professional separation assist tool. The metallic tool from Keysight scratches the external plated gold (if any)..
Got a pretty weird and unexpected situation with integrating the ES9038PRO DAC.
The whole code of the XMOS audio hardware management is included in s single file, audiohw.xc There are two functions, one to initialize the hardware, and the second to make any DAC configuration changes to acconodate different sample rates, as received through the USB endpoint.
MCLK is generated in the hardware and is applied to the DAC as soon as the XMOS board is powered up; this is required, since the I2C clock is derived from MCLK. However, LRCK and SCLK are generated in the software and are, when the DAC initialization function, not available.
DAC register programming works perfectly fine, reading the registers confirm the right values. After initialization, the program goes on and the LRCK and SCLK are eventually generated and applied to the DAC.
And here's the problem, under the circumstances, the DAC doesn't start! If I program the DAC registers at a random moment, after the LRCK and SCLK are already available, the DAC starts and everything is fine. This is for the synchronous mode (the DPLL is disabled) but it also happens in asynchronous mode. It appears that the LRCK is required for the ES9038 to start after the configuration is loaded.
The obvious solution is to load the DAC config later, after the LRCK started, by firing a timer (the I2C code is non blocking). But this would break the current XMOS framework architecture... Anybody seen this situation?
The whole code of the XMOS audio hardware management is included in s single file, audiohw.xc There are two functions, one to initialize the hardware, and the second to make any DAC configuration changes to acconodate different sample rates, as received through the USB endpoint.
MCLK is generated in the hardware and is applied to the DAC as soon as the XMOS board is powered up; this is required, since the I2C clock is derived from MCLK. However, LRCK and SCLK are generated in the software and are, when the DAC initialization function, not available.
DAC register programming works perfectly fine, reading the registers confirm the right values. After initialization, the program goes on and the LRCK and SCLK are eventually generated and applied to the DAC.
And here's the problem, under the circumstances, the DAC doesn't start! If I program the DAC registers at a random moment, after the LRCK and SCLK are already available, the DAC starts and everything is fine. This is for the synchronous mode (the DPLL is disabled) but it also happens in asynchronous mode. It appears that the LRCK is required for the ES9038 to start after the configuration is loaded.
The obvious solution is to load the DAC config later, after the LRCK started, by firing a timer (the I2C code is non blocking). But this would break the current XMOS framework architecture... Anybody seen this situation?
Chinese ES9038Q2M firmware was captured with a logic analyzer. It kept trying over and over to start up the dac until it got a certain response from one of the status registers. Don't remember which one at the moment. Other than that, ES9038PRO datasheet says to hold RESETB low until 1ms after clock has started. Don't recall if that makes any difference for this case.
Interesting, although not sure how that would work. Just a loop would be blocking, so the clocks would not have the chance to start. Must be a call from the lower layers...
In principal yes. However in ES9038PRO or Q2M BCK/LRCK lines are also used for SPDIF input. I fail to see how they would need to be started when the chip is initialized as the function of those data lines has not yet been set.
I tried register 100 (0x64). Immediately after a hardware reset is 0x01, after configuration is 0x02 (doesn't start).
If the configuration is delayed until the clocks start (and everything works fine), it's always 0x02. Which makes sense, still don't understand why the DAC is not starting.
I also tried initializing the DAC multiple times, without resets in between. Still doesn't start. and register 0x64 is then always 0x02.
I may try to switch the I2S to synchronous/blocking read/write, currently operations are non blocking. The late register initializing is done in Python, operations are synchronous/blocking.
If the configuration is delayed until the clocks start (and everything works fine), it's always 0x02. Which makes sense, still don't understand why the DAC is not starting.
I also tried initializing the DAC multiple times, without resets in between. Still doesn't start. and register 0x64 is then always 0x02.
I may try to switch the I2S to synchronous/blocking read/write, currently operations are non blocking. The late register initializing is done in Python, operations are synchronous/blocking.
Honestly I have found autodetect mode to be a bit flaky over the years and always avoid it if I can. Perhaps they have improved the MUX and spdif receiver on the ESS in the last couple generations, but I never wanted to find out (although I will likely try it again shortly with PCM/DSD content. i've always forced i2S mode and if more inputs are required, an external receiver/mux used. In my use case i'm rarely encountering DSD, due to heavy DSP.
Solved. Adding a few milliseconds of delay between registers setting did the trick. Not sure if the XMOS I2C is flaky (I already mentioned those weird spikes after the ACK bit) or the ESS state machine is too slow to take the burst of I2C from the XMOS (I am using a 400KHz clock). I tried without delay at 100KHz clock and is also fine.
I have a question regarding ES9038Q2M. My take on ES9038Q2M is basically very similar to ESS evaluation board. I'm using OPA1612 as the AVCC buffer (OPA1612 in that spot resulted in lowest noise) and OPA1656 as IV and summing opamps. I noticed that when lowering the opamp power supply from +/-15V the loopback noise floor worsened by about 0.5dB (+/-12V) or 1dB (+/-9V) but THD remained the same. What might be the cause for this?
Here is the 1k@88k2 loopback at -1dBFS with some C2/C3 compensation. Not spectacular but that may be partly due to ADC (AK5394).
Here is the 1k@88k2 loopback at -1dBFS with some C2/C3 compensation. Not spectacular but that may be partly due to ADC (AK5394).
