At Wed, 30 Jul 2008 10:11:32 +0200, Matthias Dahl wrote:
Hello.
Earlier this month I already posted about my problems with the ALC889a chip. I've gathered some more informations that might help or inform others:
the ALC889a is a custom job for Gigabyte and Realtek is not allowed to release its data sheet to anyone but Gigabyte. So no data sheet on this one.
There seem to be two revisions of this chip. I was unable to confirm this with Realtek but my revision id is 0x100101 whereas ALSA expects 0x100103.
Modifing patch_realtek.c appropriately to recognize my revision id and use patch_alc883 instead of patch_alc882, doesn't fix the problem but seems to help my initial volume problems.
What is this "initial volume problem"? Could you compare /proc/asound/card0/codec#* outputs between patched and non-patched cases?
- Sound distortions only appear on the center channel while playing back multi channel content. They sound like voltage sizzling noise. Hard to explain. Muting all channels but the center channel makes those distortions disappear.
Hm, is it via 5.1 channel output with real 6 channels? The hda-intel driver tries to duplicate 2-channel signals to 5.1 automatically, and it's known that this doesn't always work, e.g. on AD1986A codec chip. I guess this isn't the case for Realtek codecs, though.
A test under Vista revealed no distortions or anything like it. So a faulty chip is actually pretty unlikely.
A good news, at least :) In the recent patch_realtek.c, there are bunch of magical initial sequences found, e.g. in alc888_coef_init() or in alc_subsystem_id(). Can any of them change the output quality? alc_fix_pll*() is another magical code, too...
Since three weeks I am in contact with Realtek about this problem but there is not much to report on that front yet except for a rather friendly and helpful contact. Unfortunately due to time constraints and other issues, the problem hasn't been confirmed nor denied yet by Realtek. They received a similar mb from Gigabyte and are planing on trying to reproduce that problem there.
To make a long story short, I'd appreciate if anyone with an ALC889a chip and a 5.1 setup could try to confirm this bug and post about it. If anyone knows a way how I could diagnose this further, I am open to suggestions...
Currently I tend to get myself an Asus Xonar D2X or similar and keep this as a reminder that one should never buy hardware that's not in some way or another open. :-( To defend myself, when I bought my board a few weeks back I was under the impression that _all_ HDA codecs work well with ALSA and at least there I wouldn't have to worry. Well... far from it. :(
HDA codecs are often so delicate. You must care with love :)
Takashi
Thanks a lot in advance for any suggestions or help.
Have a nice day, Matthias Dahl [2 patch_realtek.c.diff <text/x-diff; us-ascii (7bit)>] --- patch_realtek.c.orig 2008-06-27 10:11:58.000000000 +0200 +++ patch_realtek.c 2008-07-11 11:46:17.000000000 +0200 @@ -6526,7 +6526,7 @@ break; default: /* ALC889A is handled better as ALC888-compatible */
if (codec->revision_id == 0x100103) {
if (codec->revision_id == 0x100103 || codec->revision_id == 0x100101) { alc_free(codec); return patch_alc883(codec); }@@ -14661,8 +14661,10 @@ { .id = 0x10ec0880, .name = "ALC880", .patch = patch_alc880 }, { .id = 0x10ec0882, .name = "ALC882", .patch = patch_alc882 }, { .id = 0x10ec0883, .name = "ALC883", .patch = patch_alc883 },
- { .id = 0x10ec0885, .rev = 0x100103, .name = "ALC889A",
- { .id = 0x10ec0885, .rev = 0x100103, .name = "ALC889A rev2", .patch = patch_alc882 }, /* should be patch_alc883() in future */
- { .id = 0x10ec0885, .rev = 0x100101, .name = "ALC889A rev1",
.patch = patch_alc883 },[3 <text/plain; us-ascii (7bit)>] _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel