Christian Wisner-Carlson wrote:
I have the H6 working somewhat. I added a lot of I2C resets (and a loop to make sure the bus is free before trying to write to it).
Can you find out when exactly the I²C bus gets wedged? (I'd guess at the first access to an off-board DAC.)
Do any of the I²C writes to the H6 actually get through (i.e., do all eight volume controls work?)
(The first D2 Windows driver versions had a bug, taken over from the AK4396 models, where it used the wrong SPI output for the fourth DAC, so that that chip would never get any register write. Nobody noticed.)
HOWEVER, when the H6 is connected, and i switch from 128x OS,
"to"?
the sound stops and becomes a high pitched whine or other noise, or just stops, as if the DACs lost lock on the MCLK signal. The same thing happens when i play ANYTHING at 96khz or 192khz sampling rate. However, 88.2khz still plays at 64x OS. Given that a 24.576MHz single-ended signalis being sent UNBUFFERED over an UNSHIELDED ribbon cable, this does not surprise me. I am guessing that the Asus drivers probably use a lower MCLK rate. Any ideas?
As far as I can tell (without running the Windows driver), it uses the standard 256x/128x MCLK rates for the standard I²S output, but the CS2000 (connected to the "ADC1" I²S MCLK) is always configured for half that rate although the PCM179x registers are still configured for the 'full' rate.
Can you find out which of the I²S MCLK outputs is used for the onboard DAC and for the H6? I'd conclude from the above that the CS2000 might be used for all of them, but then I don't know how the HDAV would work with the H6 at high clock rates.
Does the Windows driver allow 192 kHz with the H6? (This is using 128x in both drivers.)
My old Audigy 2 buffered the MCLK (24.576Mhz) with a 74F125, although I am reluctant to do this. Perhaps I will try replacing the relevent part of the ribbon cable with a shielded cable. Is this worth trying?
Better try changing mclk_from_rate() to always use the smallest possible MCLK rate; update_pcm1796_oversampling() then needs to be changed too. According to the PCM179x datasheets, up to 48 kHz requires at least 256x, while 96-192 kHz can run at 128x. (We always use I²C fast mode, even with codecs that are not documented to support it; the CMI8788 seems to be buggy at the standard I²C speed.)
Regards, Clemens