[alsa-devel] snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output
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.
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
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.
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
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
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
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
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.
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
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.
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
participants (4)
-
Matthias Dahl -
Sigi Jekabsons -
Takashi Iwai -
Zig