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). HOWEVER, when the H6 is connected, and i switch from 128x OS, 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? 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?
Christian Wisner-Carlson
On Mon, Nov 1, 2010 at 11:59 AM, Clemens Ladisch clemens@ladisch.de wrote:
Christian Wisner-Carlson wrote:
I tested this thoroughly with an Asus Xonar Essence ST, although it should also work with the HDAV, Essence STX, and probably other cards.
D2/D2X, Xense.
The patches that I am posting only give one control regardless of whether or not more than one DAC is connected. I have another patchset that gives individual control of all 4 dacs in the Xonar Essence ST+H6 and HDAV+H6 setups (H6 is an optional daughterboard for surround sound).
BTW: any new information about the H6 problem?
It allows for 4 balanced outputs, 8 unbalanced outputs, or any combination of balanced and unbalanced outputs. HOWEVER, it adds 4 mixer controls and the code isn't very pretty.
The controller can route any stereo pair to each DAC, so it would be a good idea to have one global control that also affects this routing so that, e.g., configuring the card for 4 outputs works correctly when playing 4-channel data.
Alternatively, having low-level controls for each detail of the hardware is workable when somebody (i.e., you :-) writes a special graphical tool to configure the Xonar outputs (any the other settings).
The Xense has one PCM1796 for the front channels and a CS4362A for the other channels. Like the stereo-only cards, this would result in an odd number of channels in balanced mode, which is somewhat counterintuitive because the controller would need to be fed an extra unused channel.
Please tell me if this is not the correct way to post a patch, and tell me if it seems like a candidate to be merged.
Your mailer wrapped lines; see Documentation/email-clients.txt. Also see Documentation/SubmittingPatches.
Overall, this patch looks good. But I wouldn't want to apply it without the followup patch that handles the D2's four DACs.
@@ -532,6 +534,13 @@ reg = PCM1796_OS_64; else reg = PCM1796_OS_32;
- if (data->monomode)
- reg = reg | PCM1796_MONO;
- if (data->rightmono)
- reg = reg | PCM1796_CHSL_RIGHT;
for (i = 0; i < data->dacs; ++i) pcm1796_write_cached(chip, i, 20, reg); }
This function's purpose is no longer to _only_ update the oversampling setting; please rename it to, e.g., update_reg20.
Regards, Clemens _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel