At Thu, 28 Sep 2006 00:37:19 +0200, Mariusz Domanski wrote: > > > 2006/9/27, Takashi Iwai <tiwai@xxxxxxx>: > > At Tue, 26 Sep 2006 20:14:58 +0200, > Mariusz Domanski wrote: > > > > I have codec#0 output saved when everything was working. > > There is little change according to outpiu which codec#0 gives me now. > > > > Part of "good" codec#0: > > Node 0x15 [Audio Mixer] wcaps 0x20050f: Stereo Amp-In Amp-Out > > Amp-In caps: ofs=0x0c, nsteps=0x17, stepsize=0x0b, mute=1 > > Amp-In vals: [0x95 0x95] [0x80 0x80] [0x80 0x80] > > Amp-Out caps: ofs=0x0c, nsteps=0x0c, stepsize=0x0b, mute=1 > > Amp-Out vals: [0x0c 0x0c] > > Power: 0x0 > > Connection: 3 > > 0x11 0x14 0x1c > > > > Now the 3rd line is: > > Amp-In vals: [0x95 0x95] [0x95 0x95] [0x95 0x95] > > Above all, _what_ happened by this change? > > > This is the only change. > > > > What does this mean? > > It means that the amp-input values are changed. > But they are still muted (bit 7 [0x80] is on), so in theory, they > shouldn't make any difference. No other changes at all? > > > How can I change it? > > Via mixer elements, most likely. > You can check the mixer elements you created which ones have the NID > 0x15 (and INPUT direction). > > > Can this cause this whole strange problem? > > You'd better to take a look at the block diagram in ALC861 datasheet > to understand what's happning. > > The widget 0x15 is "analog mixer" that takes all inputs from line, > mic, etc and passes to ADC and the output mixer. The three values are > volumes from inputs to this mixer from CD, line and mic input pins. > > > I can try to change something but I don't know what exactly should be changed, > so > > i'll be changing various values :P > > That's my question, too. First, you have to recognize the way to > reproduce the problem. Debugging randomly happening problem is quite > hard. We need to know the cause, not only the result. > > Takashi > > Well that's great question... What cause the problem? I really would like to know... > :) > If I would know how to reproduce this problem I would tell > you... If you can ever get a "good" state, then there must be a cause. You need to find out how to get a good and a bad state, the step to reproduce (e.g. first boot Windows, or whatever). Then check the internal state of the device. This is the most important thing to debug this kind of problems. > I mean now this problem is present - headphones are not working :P > codec#0 shows PIN_OUT (0x40) on headphones jack, but there is no sound... Which PIN node? The headphone jack takes usually PIN_HP (0xc0) with HP-overdrive bit. You should also trace the connection line between the pin and DAC, and check whether all widgets are unmuted/adjusted throughout the line. > I can tell you that when line-in is unmuted and master mixer and line-in mixers > are set to 100% I'm about to hear music... It's very very quiet and > with high frequency noises... Sorry, it's not clear what you mean here. Please describe more exactly what you did, step by step? > The most strange thing is that, as I wrote before, the sound was and > disappeard after > Alsa restart... Is the device state restored via alsactl automatically? Usually, udev takes a charge to call "alsactl restore" after module reloading. You can call "alsactl save" before restart, and call "alsactl restore" after restart manually. > Does Alsa have any config files that could be changed during restart? > What can be changed during Alsa restart? The device is set up to be muted per default (depending on the driver implementation, though). You have to adjust it to unmuted state. Calling "alsactl restore" would restore to the last saved state. This whole thing depends on the distribution you use. I cannot tell the exact detail. > I'll try to make the headphones working... What should I do if I'll do it? Any > special things to do? Has the headphone _ever_ worked? If not, we can do only blind shots. > What about looking at datasheet... Well... I don't understand much, > I'm not a driver > programmer. I just can think and read and I'm trying to make > something knowing almost nothing :) > > Now I'm looking at datasheet and can only tell what I knew earlier: > PORT-A - SURR-OUT - 0x0e - surround, but in my case hp jack (?) [let > say it can work] OK, that's good to know. > PORT-B - MIC1 - 0x0d - mic jack or built-in mic [works] > PORT-C - LINE1 - 0x0c - line-in jack [propably works, I have nothing to test it] > PORT-D - FRONT - 0x0b - front out (built-in speakers) [works] Is it muted automatically when HP is plugged, or it still continues to output sounds? If it keeps sound, we'll need a pin detection (if auto-toggling feature is needed). > PORT-E - LINE2 - 0x0f - usually hp, but not in my case, has to be > set to 0x24 (mic-input as I understand) or nothing does work... 0x24 is to set INPUT and VREF 80%. Yes, it's a usual setting for mic input. > PORT-F - MIC2 - 0x10 - built-in mic or mic jack [works] Hm, what is the difference from port-B? Takashi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
