snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Matthias Dahl]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

Hello everyone.

I very recently upgraded my system to a Asus Crosshair (AM2, nforce 590 sli) 
board because it seemed just good quality. Unfortunately the AD1988b chip on 
it is causing me some trouble.

1] SPDIF output 

When I use it for dts/dolby passthrough, it works just fine even though from 
time to time spdif just hangs- not during playback but when I start the 
playback. (analog output is unaffected) Meaning that either the player is 
hanging or playback starts but I hear no sound. After that only a reboot 
solves the problem... restarting alsa has not effect.

Also when the passthrough stops or during playback of anything else besides a 
dts/dolby stream, I hear a low pitch beating (usually in combination with a 
very high pitch sound) in the background.

I double checked everything to be sure that my other equipment was fine and 
not the cause of this.

2] analog output

I am unable to get it as loud as with the win drivers without overdriving it. 
The volume is okay... but not on par with the win drivers. That's especially 
true for the SPDIF output. Increasing the SPDIF volume usually results in 
worse audio quality over spdif and increased "noise" (see above).

Like said earlier, I checked with the win drivers, and everything (audio wise) 
works just fine there. So it's not a hardware fault. (relief -g-)

My guess would be that the AD 1988b is quite a bit different to program from 
its 1988 predecessors as it contains dts live and stuff. Just a guess...

I have attached some hopefully useful informations. If you need anything else, 
please let me know. I really need that spdif working, so I am more than 
willing to test just about anything. :-)

Last but not leat, I have tried the latest official alsa drivers as well as a 
mercurial snapshot from yesterday. (which I am currently using) Both show the 
same problems.

Thanks for any help in advance,
matthew.

[-- Attachment #2: lspci_output.gz --]
[-- Type: application/x-gzip, Size: 3321 bytes --]

[-- Attachment #3: proc_output1.gz --]
[-- Type: application/x-gzip, Size: 1747 bytes --]

[-- Attachment #4: proc_output2.gz --]
[-- Type: application/x-gzip, Size: 401 bytes --]

[-- Attachment #5: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Takashi Iwai]

At Tue, 17 Jul 2007 08:32:00 +0200,
Matthias Dahl wrote:
> 
> Hello everyone.
> 
> I very recently upgraded my system to a Asus Crosshair (AM2, nforce 590 sli) 
> board because it seemed just good quality. Unfortunately the AD1988b chip on 
> it is causing me some trouble.
> 
> 1] SPDIF output 
> 
> When I use it for dts/dolby passthrough, it works just fine even though from 
> time to time spdif just hangs- not during playback but when I start the 
> playback. (analog output is unaffected) Meaning that either the player is 
> hanging or playback starts but I hear no sound. After that only a reboot 
> solves the problem... restarting alsa has not effect.
> 
> Also when the passthrough stops or during playback of anything else besides a 
> dts/dolby stream, I hear a low pitch beating (usually in combination with a 
> very high pitch sound) in the background.
> 
> I double checked everything to be sure that my other equipment was fine and 
> not the cause of this.

Which applications are you using? 

For further analysis, first get /proc/asound/card0/codec#* files for
both working and non-working states.  This includes most of codec
register information, so we can compare the details.  In addition, run
"alsactl -f somefile store" in both cases, too.  This file contains
the mixer status.

Also, check the kernel messages when it hangs.  If it's related to the
controller communication error, it must show some timeout messages.


> 2] analog output
> 
> I am unable to get it as loud as with the win drivers without overdriving it. 
> The volume is okay... but not on par with the win drivers. That's especially 
> true for the SPDIF output. Increasing the SPDIF volume usually results in 
> worse audio quality over spdif and increased "noise" (see above).
> 
> Like said earlier, I checked with the win drivers, and everything (audio wise) 
> works just fine there. So it's not a hardware fault. (relief -g-)
> 
> My guess would be that the AD 1988b is quite a bit different to program from 
> its 1988 predecessors as it contains dts live and stuff. Just a guess...

No, it's almost same (if we rely on the datasheet).

Did you try any model module option?  It might be a BIOS problem that
doesn't set up the codec informatoin correctly.  With model option, we
can override and use the preset configuration.


Takashi

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Matthias Dahl]

On Tuesday 17 July 2007 12:21:25 Takashi Iwai wrote:

> Which applications are you using?

Tested with amarok, kaffeine (and thus xine), mplayer, alsaplayer...

> For further analysis, first get /proc/asound/card0/codec#* files for
> both working and non-working states.  This includes most of codec
> register information, so we can compare the details.  In addition, run
> "alsactl -f somefile store" in both cases, too.  This file contains
> the mixer status.

Okay... it's hard to force it, so next time something like that happens, I 
will get the informations you asked for. (I already attached several infos to 
my last mail) Is there something else I can do or provide you with in the 
meantime...?

> Also, check the kernel messages when it hangs.  If it's related to the
> controller communication error, it must show some timeout messages.

There are no kernel msgs... already checked that.

> No, it's almost same (if we rely on the datasheet).

Different revision maybe...?

> Did you try any model module option?  It might be a BIOS problem that
> doesn't set up the codec informatoin correctly.  With model option, we
> can override and use the preset configuration.

Yeah... tried several things so far.


1] model option

With the auto setting, I can raise the volume a lot louder. Unfortunately 
every sound I play back through spdif (non-ac3) seems overamplified even if I 
lower the iec958 volume below -45db. I cannot get that right. Also in order 
to correctly set the front volume, I have to adjust the headphone volume as 
well. If I don't, the front sounds dull somehow. Also tried other variants 
but usually one of the speakers isn't working or stuff like that.

Currently I am using 6stack-dig with the problems outlined in my earlier mail.

Unfortunately neither with the auto setting, nor with 6stack-dig, I am able to 
switch the output mode (6 channel, 2 channel, ...). It's always 6 channels 
and whatever I play back is routed to every speaker. :-(

2] position_fix

I don't seem to have any luck with that one. Doesn't solve any problems... 
with setting at 3, things are even worse with more distortions.


So... I could live with the occasional spdif hang but is there something I can 
do about those distortions I hear with spdif and non-ac3 stuff played back? I 
can even hear it when nothing is being played back. Interestingly, the 
distortions are gone when ever I have played back something ac3 (passthrough) 
until I play back something non-ac3.

Thanks again,
matthew.

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Takashi Iwai]

At Tue, 17 Jul 2007 18:22:56 +0200,
Matthias Dahl wrote:
> 
> On Tuesday 17 July 2007 12:21:25 Takashi Iwai wrote:
> 
> > Which applications are you using?
> 
> Tested with amarok, kaffeine (and thus xine), mplayer, alsaplayer...
> 
> > For further analysis, first get /proc/asound/card0/codec#* files for
> > both working and non-working states.  This includes most of codec
> > register information, so we can compare the details.  In addition, run
> > "alsactl -f somefile store" in both cases, too.  This file contains
> > the mixer status.
> 
> Okay... it's hard to force it, so next time something like that happens, I 
> will get the informations you asked for. (I already attached several infos to 
> my last mail) Is there something else I can do or provide you with in the 
> meantime...?
> 
> > Also, check the kernel messages when it hangs.  If it's related to the
> > controller communication error, it must show some timeout messages.
> 
> There are no kernel msgs... already checked that.
> 
> > No, it's almost same (if we rely on the datasheet).
> 
> Different revision maybe...?

Might be.  But I don't know of revision differences in details.

> > Did you try any model module option?  It might be a BIOS problem that
> > doesn't set up the codec informatoin correctly.  With model option, we
> > can override and use the preset configuration.
> 
> Yeah... tried several things so far.
> 
> 
> 1] model option
> 
> With the auto setting, I can raise the volume a lot louder. Unfortunately 
> every sound I play back through spdif (non-ac3) seems overamplified even if I 
> lower the iec958 volume below -45db. I cannot get that right. Also in order 
> to correctly set the front volume, I have to adjust the headphone volume as 
> well. If I don't, the front sounds dull somehow. Also tried other variants 
> but usually one of the speakers isn't working or stuff like that.
> 
> Currently I am using 6stack-dig with the problems outlined in my earlier mail.

So, the primary problem is rather the 6stack-dig preset doesn't match
with your device.  The SPDIF problem seems independent, though, but
we'd better to fix the stuff first.

With auto model, do you get louder output from the analog out?


> Unfortunately neither with the auto setting, nor with 6stack-dig, I am able to 
> switch the output mode (6 channel, 2 channel, ...). It's always 6 channels 
> and whatever I play back is routed to every speaker. :-(

Then the BIOS configuration is broken (or the driver implementation is
buggy).

The first thing to do is to check which pin widget corresponds to the
real I/O jacks.  It's a guess work and trial-and-error.


> 2] position_fix
> 
> I don't seem to have any luck with that one. Doesn't solve any problems... 
> with setting at 3, things are even worse with more distortions.

Then it's fine.  It's a good news.  Your device isn't buggy about
this, at least.


Takashi

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Matthias Dahl]

On Thursday 19 July 2007 15:50:19 Takashi Iwai wrote:

> So, the primary problem is rather the 6stack-dig preset doesn't match
> with your device.  The SPDIF problem seems independent, though, but
> we'd better to fix the stuff first.
>
> With auto model, do you get louder output from the analog out?

Just tested it and as far as I can tell, only spdif seems a lot louder, analog 
output is equal to 6stack-dig.

Reminds me what also a bit strange: the PCM mixer control only appears after I 
have played back something.

On detail: - unload alsa, rm asound.state, load alsa, alsamixer (no pcm vol)
           - play back something, alsamixer (pcm volume is there)

>From there on, it'll always be visible, even after restarts. I also do not 
have any channel configuration control (2/4/6 channels). It's just not there. 
No matter if I use auto or 6stack-dig.

> The first thing to do is to check which pin widget corresponds to the
> real I/O jacks.  It's a guess work and trial-and-error.

Sounds a lot like digging into patch_analog.c (a long change/recompile/test 
cycle) or is there a way to figure this stuff out during runtime...? Could 
you please elobrate on what I should do? Thanks.

Best regards,
Matthias Dahl

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Takashi Iwai]

At Fri, 20 Jul 2007 08:29:02 +0200,
Matthias Dahl wrote:
> 
> On Thursday 19 July 2007 15:50:19 Takashi Iwai wrote:
> 
> > So, the primary problem is rather the 6stack-dig preset doesn't match
> > with your device.  The SPDIF problem seems independent, though, but
> > we'd better to fix the stuff first.
> >
> > With auto model, do you get louder output from the analog out?
> 
> Just tested it and as far as I can tell, only spdif seems a lot louder, analog 
> output is equal to 6stack-dig.

OK.  You may be able to figure out what influences on the volume by
comparing /proc/asound/card0/codec#* file on both models.

> Reminds me what also a bit strange: the PCM mixer control only appears after I 
> have played back something.
> 
> On detail: - unload alsa, rm asound.state, load alsa, alsamixer (no pcm vol)
>            - play back something, alsamixer (pcm volume is there)
> 
> From there on, it'll always be visible, even after restarts. I also do not 
> have any channel configuration control (2/4/6 channels). It's just not there. 
> No matter if I use auto or 6stack-dig.

This is expected behavior.  The PCM volume is implemented via softvol
plugin, and it creates dynamically at the first run.  But, usually,
it's restored via alsactl at the next boot.

> > The first thing to do is to check which pin widget corresponds to the
> > real I/O jacks.  It's a guess work and trial-and-error.
> 
> Sounds a lot like digging into patch_analog.c (a long change/recompile/test 
> cycle) or is there a way to figure this stuff out during runtime...? Could 
> you please elobrate on what I should do? Thanks.

Yes, it'll involve with patch_analog.c deeply.  Basically you need to
modify init verb table and the mixer element table.  Check the AD1988B
datasheet, and try to assign the different PIN (and corresponding
mixer / selector widgets) in init verb and mixer tables.  Then,
rebuild driver, and try the driver until you get the complete mapping
of pin widgets.


Takashi

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Matthias Dahl]

Hello Takashi.

On Friday 20 July 2007 15:47:55 Takashi Iwai wrote:

> This is expected behavior.  The PCM volume is implemented via softvol
> plugin, and it creates dynamically at the first run.  But, usually,
> it's restored via alsactl at the next boot.

It is. Thanks for the info.

> Yes, it'll involve with patch_analog.c deeply.  Basically you need to
> modify init verb table and the mixer element table.  Check the AD1988B
> datasheet, and try to assign the different PIN (and corresponding
> mixer / selector widgets) in init verb and mixer tables.  Then,
> rebuild driver, and try the driver until you get the complete mapping
> of pin widgets.

I am currently a bit limited in time (end of semester exams) but after a few 
hours of playing around (and reading the specs) I figured the following:

1) From time to time no analog output is routed to the spdif anymore. The only
   clue I could get is the "IEC958 Playback Default" which is set to

   06820002 [... many more zeros ...]

   and thus restored to that value after reboots. When things work like they
   should (analog output is routed to spdif), its value is

   04820002 [... many more zeros ...]

   Manually setting it to this value naturally solves the problem. I have yet
   to figure out how to trigger this problem?! It seems to happen rather
   randomly. In both cases, ac3 passthrough works just fine btw.


2) I have come a step closer in solving the analog-to-spdif volume/distortions
   problem... at least I hope. 

   The following patch fixes the volume problem for me. Without it, I had to
   set the IEC958 volume somewhere around 58... increasing it would result in
   noticable clipping and even short audio gaps (noise).

   Honestly, I don't quite understand the purpose of the code I removed in the
   first place. From what I figured reading the specs and the code, the spdif
   in is mixed with the spdif out stream... but that's all I could gather. But
   still it doesn't seem quite right to me.

--- patch_analog.c.orig 2007-07-23 22:44:25.000000000 +0200
+++ patch_analog.c      2007-07-23 22:45:15.000000000 +0200
@@ -2037,12 +2037,8 @@
 static struct hda_verb ad1988_spdif_init_verbs[] = {
        /* SPDIF out sel */
        {0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */
-       {0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */
-       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
-       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
        /* SPDIF out pin */
        {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x27}, /* 0dB */
-       {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */

        { }
 };

    The audio distortions in the background have become a little less noisy
    but are still there. (a bass-like pumping, some white noise and sometimes
    some high frequency tone) But the volume works just fine now... (iec958
    vol at 100%) and the audio sounds somewhat "clearer"!

Sorry I couldn't get any further so far. I hope this maybe gives some clues to 
you what else could be wrong after all. The chip works just fine under win, 
if it weren't for that, I'd blame the hw.

Best regards,
Matthias Dahl

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Zig]

Matthias Dahl <ml_alsa <at> mortal-soul.de> writes:

> 
> --- patch_analog.c.orig 2007-07-23 22:44:25.000000000 +0200
> +++ patch_analog.c      2007-07-23 22:45:15.000000000 +0200
>  <at>  <at>  -2037,12 +2037,8  <at>  <at> 
>  static struct hda_verb ad1988_spdif_init_verbs[] = {
>         /* SPDIF out sel */
>         {0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */
> -       {0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */
> -       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
> -       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
>         /* SPDIF out pin */
>         {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x27}, /* 0dB */
> -       {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */
> 
>         { }
>  };

> 

I had similar issues, however patching the file as shown above caused no audio
output at all on the SPDIF unless it was in AC3 passthrough mode.  Instead I
edited my patch_analog.c file as follows:

static struct hda_verb ad1988_spdif_init_verbs[] = {
        /* SPDIF out sel */
        {0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */
//      {0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */
        {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
        {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)},
        /* SPDIF out pin */
        {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x17}, /* 0dB */
//      {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */

        { }
};

Once I compiled it this was, the noise on the SPDIF output was gone, and
everything functioned correctly.

It does seem my original issue was related to the PCM audio being outputted at
48kHz instead of 44.1kHz?  Thats what my sony amplifier seemed to think anyhow.

Thanks for your original patch, really I don't know what I'm doing with this
thing, and made a lucky guess for my purposes.

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Takashi Iwai]

At Sat, 18 Aug 2007 14:31:35 +0000 (UTC),
Zig wrote:
> 
> Matthias Dahl <ml_alsa <at> mortal-soul.de> writes:
> 
> > 
> > --- patch_analog.c.orig 2007-07-23 22:44:25.000000000 +0200
> > +++ patch_analog.c      2007-07-23 22:45:15.000000000 +0200
> >  <at>  <at>  -2037,12 +2037,8  <at>  <at> 
> >  static struct hda_verb ad1988_spdif_init_verbs[] = {
> >         /* SPDIF out sel */
> >         {0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */
> > -       {0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */
> > -       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
> > -       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
> >         /* SPDIF out pin */
> >         {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x27}, /* 0dB */
> > -       {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */
> > 
> >         { }
> >  };
> 
> > 
> 
> I had similar issues, however patching the file as shown above caused no audio
> output at all on the SPDIF unless it was in AC3 passthrough mode.

Then it must be a usage error.  In the ALSA system, the same stream is
used regardless of audio or non-audio data.

It might be that you set non-audio bit permanently.  Verify with
iecset program in alsa-utils package.


Takashi

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Sigi Jekabsons]

Takashi Iwai wrote:
> Then it must be a usage error.  In the ALSA system, the same stream is
> used regardless of audio or non-audio data.
>
> It might be that you set non-audio bit permanently.  Verify with
> iecset program in alsa-utils package.
>
>
> Takashi
>   
Audio mode is enabled.  I haven't made any other changes since compiling 
in the modifications I mentioned earlier.  I wasn't aware of this 
utility before looking up this thread however, so I don't know what the 
data rate or mode it was running before. 

Thanks.

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Takashi Iwai]

At Mon, 20 Aug 2007 17:35:46 +0800,
Sigi Jekabsons wrote:
> 
> 
> Takashi Iwai wrote:
> > Then it must be a usage error.  In the ALSA system, the same stream is
> > used regardless of audio or non-audio data.
> >
> > It might be that you set non-audio bit permanently.  Verify with
> > iecset program in alsa-utils package.
> >
> >
> > Takashi
> >   
> Audio mode is enabled.  I haven't made any other changes since compiling 
> in the modifications I mentioned earlier.

Well, the strange thing is that the line you commented out (the
connection select of 0x0b) is overwritten via "IEC95 Playback Source"
control.  Is it set to "PCM"?

And, check the AMP and connection of the widgets 0x0b and 0x1b via
codec#0 file.  Are these values really different from what you
commented out?


Takashi

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Takashi Iwai]

At Mon, 23 Jul 2007 23:02:57 +0200,
Matthias Dahl wrote:
> 
> Hello Takashi.
> 
> On Friday 20 July 2007 15:47:55 Takashi Iwai wrote:
> 
> > This is expected behavior.  The PCM volume is implemented via softvol
> > plugin, and it creates dynamically at the first run.  But, usually,
> > it's restored via alsactl at the next boot.
> 
> It is. Thanks for the info.
> 
> > Yes, it'll involve with patch_analog.c deeply.  Basically you need to
> > modify init verb table and the mixer element table.  Check the AD1988B
> > datasheet, and try to assign the different PIN (and corresponding
> > mixer / selector widgets) in init verb and mixer tables.  Then,
> > rebuild driver, and try the driver until you get the complete mapping
> > of pin widgets.
> 
> I am currently a bit limited in time (end of semester exams) but after a few 
> hours of playing around (and reading the specs) I figured the following:
> 
> 1) From time to time no analog output is routed to the spdif anymore. The only
>    clue I could get is the "IEC958 Playback Default" which is set to
> 
>    06820002 [... many more zeros ...]
> 
>    and thus restored to that value after reboots. When things work like they
>    should (analog output is routed to spdif), its value is
> 
>    04820002 [... many more zeros ...]
> 
>    Manually setting it to this value naturally solves the problem. I have yet
>    to figure out how to trigger this problem?! It seems to happen rather
>    randomly. In both cases, ac3 passthrough works just fine btw.

Maybe some apps change the IEC958 status bits and doesn't restore the
original value at close.  (Or interrupting via ctrl-C may cause it.)

You can see the meaning of these bits via iecset utility included in
alsa-utils package.


> 2) I have come a step closer in solving the analog-to-spdif volume/distortions
>    problem... at least I hope. 
> 
>    The following patch fixes the volume problem for me. Without it, I had to
>    set the IEC958 volume somewhere around 58... increasing it would result in
>    noticable clipping and even short audio gaps (noise).
> 
>    Honestly, I don't quite understand the purpose of the code I removed in the
>    first place. From what I figured reading the specs and the code, the spdif
>    in is mixed with the spdif out stream... but that's all I could gather. But
>    still it doesn't seem quite right to me.
> 
> --- patch_analog.c.orig 2007-07-23 22:44:25.000000000 +0200
> +++ patch_analog.c      2007-07-23 22:45:15.000000000 +0200
> @@ -2037,12 +2037,8 @@
>  static struct hda_verb ad1988_spdif_init_verbs[] = {
>         /* SPDIF out sel */
>         {0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */
> -       {0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */
> -       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
> -       {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
>         /* SPDIF out pin */
>         {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x27}, /* 0dB */
> -       {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */
> 
>         { }
>  };
> 
>     The audio distortions in the background have become a little less noisy
>     but are still there. (a bass-like pumping, some white noise and sometimes
>     some high frequency tone) But the volume works just fine now... (iec958
>     vol at 100%) and the audio sounds somewhat "clearer"!

So, the culprit looks like the analog loopback.
Could you try the patch below, and make sure that you set "PCM" as the
"IEC958 Playback Source"?


thanks,

Takashi

diff -r c2078875c0cd pci/hda/patch_analog.c
--- a/pci/hda/patch_analog.c	Tue Jul 24 12:10:34 2007 +0200
+++ b/pci/hda/patch_analog.c	Tue Jul 24 12:47:42 2007 +0200
@@ -1889,16 +1889,19 @@ static int ad1988_spdif_playback_source_
 	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
 	unsigned int sel;
 
-	sel = snd_hda_codec_read(codec, 0x02, 0, AC_VERB_GET_CONNECT_SEL, 0);
-	if (sel > 0) {
+	sel = snd_hda_codec_read(codec, 0x1d, 0, AC_VERB_GET_AMP_GAIN_MUTE,
+				 AC_AMP_GET_INPUT);
+	if (!(sel & 0x80))
+		ucontrol->value.enumerated.item[0] = 0;
+	else {
 		sel = snd_hda_codec_read(codec, 0x0b, 0,
 					 AC_VERB_GET_CONNECT_SEL, 0);
 		if (sel < 3)
 			sel++;
 		else
 			sel = 0;
+		ucontrol->value.enumerated.item[0] = sel;
 	}
-	ucontrol->value.enumerated.item[0] = sel;
 	return 0;
 }
 
@@ -1910,17 +1913,32 @@ static int ad1988_spdif_playback_source_
 	int change;
 
 	val = ucontrol->value.enumerated.item[0];
-	sel = snd_hda_codec_read(codec, 0x02, 0, AC_VERB_GET_CONNECT_SEL, 0);
 	if (!val) {
-		change = sel != 0;
-		if (change || codec->in_resume)
-			snd_hda_codec_write(codec, 0x02, 0,
-					    AC_VERB_SET_CONNECT_SEL, 0);
+		sel = snd_hda_codec_read(codec, 0x1d, 0,
+					 AC_VERB_GET_AMP_GAIN_MUTE,
+					 AC_AMP_GET_INPUT);
+		change = sel & 0x80;
+		if (change || codec->in_resume) {
+			snd_hda_codec_write(codec, 0x1d, 0,
+					    AC_VERB_SET_AMP_GAIN_MUTE,
+					    AMP_IN_UNMUTE(0));
+			snd_hda_codec_write(codec, 0x1d, 0,
+					    AC_VERB_SET_AMP_GAIN_MUTE,
+					    AMP_IN_MUTE(1));
+		}
 	} else {
-		change = sel == 0;
-		if (change || codec->in_resume)
-			snd_hda_codec_write(codec, 0x02, 0,
-					    AC_VERB_SET_CONNECT_SEL, 1);
+		sel = snd_hda_codec_read(codec, 0x1d, 0,
+					 AC_VERB_GET_AMP_GAIN_MUTE,
+					 AC_AMP_GET_INPUT | 0x01);
+		change = sel & 0x80;
+		if (change || codec->in_resume) {
+			snd_hda_codec_write(codec, 0x1d, 0,
+					    AC_VERB_SET_AMP_GAIN_MUTE,
+					    AMP_IN_MUTE(0));
+			snd_hda_codec_write(codec, 0x1d, 0,
+					    AC_VERB_SET_AMP_GAIN_MUTE,
+					    AMP_IN_UNMUTE(1));
+		}
 		sel = snd_hda_codec_read(codec, 0x0b, 0,
 					 AC_VERB_GET_CONNECT_SEL, 0) + 1;
 		change |= sel != val;
@@ -2039,10 +2057,9 @@ static struct hda_verb ad1988_spdif_init
 	{0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */
 	{0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */
 	{0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
-	{0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
+	{0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)},
 	/* SPDIF out pin */
 	{0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x27}, /* 0dB */
-	{0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */
 
 	{ }
 };

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Matthias Dahl]

On Tuesday 24 July 2007 12:47:59 Takashi Iwai wrote:

> Maybe some apps change the IEC958 status bits and doesn't restore the
> original value at close.  (Or interrupting via ctrl-C may cause it.)
>
> You can see the meaning of these bits via iecset utility included in
> alsa-utils package.

Thanks. I'll keep that in mind and check things when it happens again.

> So, the culprit looks like the analog loopback.
> Could you try the patch below, and make sure that you set "PCM" as the
> "IEC958 Playback Source"?

I can confirm this definitely solves the volume problem for me. I can increase 
the pcm and spdif volume to 100% and no clipping or distortions whatsoever 
happen on the spdif output. Works like a charm.

So far the other distortions I wrote about are now only hearable when I turn 
up the volume of my headphone to nearly its maximum. If it stays that way, I 
can live with it... reminds me, before the problem was fixed, I had my 
headphone at almost 100% most of the time, so that could be the reason why 
those distortions where so visible in the first place. I'll have an eye on 
it...

I am curious, will that patch make it into the offical mercurial repository 
and what was the problem exactly with the analog loopback?

Thanks for taking the time!

Best regards,
Matthias Dahl

Re: snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output

[Takashi Iwai]

At Tue, 24 Jul 2007 17:58:12 +0200,
Matthias Dahl wrote:
> 
> > So, the culprit looks like the analog loopback.
> > Could you try the patch below, and make sure that you set "PCM" as the
> > "IEC958 Playback Source"?
> 
> I can confirm this definitely solves the volume problem for me. I can increase 
> the pcm and spdif volume to 100% and no clipping or distortions whatsoever 
> happen on the spdif output. Works like a charm.

Great, thanks for confirmation.

> So far the other distortions I wrote about are now only hearable when I turn 
> up the volume of my headphone to nearly its maximum. If it stays that way, I 
> can live with it... reminds me, before the problem was fixed, I had my 
> headphone at almost 100% most of the time, so that could be the reason why 
> those distortions where so visible in the first place. I'll have an eye on 
> it...

I'm not sure whether it's a driver problem or a hardware problem.
Is the dB above 0 in the maximum level?

> I am curious, will that patch make it into the offical mercurial repository 
> and what was the problem exactly with the analog loopback?

Yes, the patch will be merged soon.  Hopefully we can put it to 2.6.23
tree, too.

The problem was that the analog loopback is routed wrongly to the
SPDIF output unconditionally, and no way to cut it out.
The patch fixes the implementation of "IEC958 playback source" mixer
element to handle correctly it.


Takashi