intel 8x0 went silent in 2.6.11

[Pierre Ossman]

I just upgraded to Linux 2.6.11 and the soundcard on my machine went
silent. All volume controls are correct and there are no errors
reported. But no sound coming from the speakers. And here's the kicker,
the headphones work fine!
2.6.10 still works so the bug appeared in one of the patches in between.
The sound card is the one integrated into intels mobile ICH4 chipset.

Rgds
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Nish Aravamudan]

On Thu, 03 Mar 2005 13:51:40 +0100, Pierre Ossman <drzeu...@drzeus.cx> wrote:
> I just upgraded to Linux 2.6.11 and the soundcard on my machine went
> silent. All volume controls are correct and there are no errors
> reported. But no sound coming from the speakers. And here's the kicker,
> the headphones work fine!
> 2.6.10 still works so the bug appeared in one of the patches in between.
> The sound card is the one integrated into intels mobile ICH4 chipset.

There was some discussion of this on LKML a while ago. Are you sure
you have disabled "Headphone Jack Sense" and "Line Jack Sense" in
alsamixer?

Thanks,
Nish

[Mark Canter]

The same issue exists on a T42p (ICH4). Doesn't that kind of defeat the
purpose? The thought of having to disable the headphone jack and reenable
it each time is trivial considering you can go with the fact that sound
did not require the sound system touched under <= 2.6.10.

+----------------------------------------------------+
| Mark Canter (mar...@vfxcomputing.com) |
| http://www.vfxcomputing.com |
+----------------------------------------------------+

[Lee Revell]

On Thu, 2005-03-03 at 13:46 -0500, Mark Canter wrote:
> The same issue exists on a T42p (ICH4). Doesn't that kind of defeat the
> purpose? The thought of having to disable the headphone jack and reenable
> it each time is trivial considering you can go with the fact that sound
> did not require the sound system touched under <= 2.6.10.

You don't have to disable and re-enable it each time, if your system is
configured correctly then your mixer settings will be saved.

Lee

[Lee Revell]

This is the place to report any more information on this issue:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=852

[Nish Aravamudan]

On Thu, 3 Mar 2005 14:06:38 -0500 (EST), Mark Canter
<mar...@vfxcomputing.com> wrote:
>
> Correct, but if you want to use your headphones you would have to enable
> headphones on your mixer, which would negate your speaker output through
> your docking station's output. If you want to use the docking station
> speakers, you would have to disable the headphones in order to get the
> docking station speakers to work; no? If that is the case, then you would
> still have to enable/disable each time you wanted to change the direction
> of headphones/external speakers. Again, this is not the case under <=
> 2.6.10 where it works regardless of enabling/disabling headphones.

I am not seeing this behavior. The Sense alsamixer entries do not to
be toggled ever again once they have been muted (for me, at least).
Both the t41p speakers and headphone jack work (with the speakers
being muted when headphones are plugged in).

Thanks,
Nish

[Mark Canter]

To close this issue out of the LKML and alsa-devel, a bug report has been
written.

It appears to be an issue with the 'headphone jack sense' (as kde labels
it). The issue is in the way the 8x0 addresses the docking station/port
replicator's audio output jack. The mentioned quick fix does not work for
using the ds/pr audio output, but does resolve it for a user that is only
using headphones/internal speakers.

mark

[Pierre Ossman]

Nish Aravamudan wrote:

>On Thu, 03 Mar 2005 13:51:40 +0100, Pierre Ossman <drzeu...@drzeus.cx> wrote:
>
>
>>I just upgraded to Linux 2.6.11 and the soundcard on my machine went
>>silent. All volume controls are correct and there are no errors
>>reported. But no sound coming from the speakers. And here's the kicker,
>>the headphones work fine!
>>2.6.10 still works so the bug appeared in one of the patches in between.
>>The sound card is the one integrated into intels mobile ICH4 chipset.
>>
>>
>
>There was some discussion of this on LKML a while ago. Are you sure
>you have disabled "Headphone Jack Sense" and "Line Jack Sense" in
>alsamixer?
>
>Thanks,
>Nish
>
>

This has been rather wildly debated now but yes, muting those enables
sound. I don't have a docking station so I can't try any effects there.
I wouldn't say that it's intuitive to mute two channels to get speakers
working though.

Rgds
Pierre

[Pierre Ossman]

Andrew Morton wrote:

>Mark Canter <mar...@vfxcomputing.com> wrote:
>
>
>>To close this issue out of the LKML and alsa-devel, a bug report has been
>>written.
>>
>>It appears to be an issue with the 'headphone jack sense' (as kde labels
>>it). The issue is in the way the 8x0 addresses the docking station/port
>>replicator's audio output jack. The mentioned quick fix does not work for
>>using the ds/pr audio output, but does resolve it for a user that is only
>>using headphones/internal speakers.
>>
>>
>

>But there was a behavioural change: applications which worked in 2.6.10
>don't work in 2.6.11, is that correct?
>
>If so, the best course of action is to change the kernel so those
>applications work again. Can that be done?
>
>
>
Yes. Speakers worked in 2.6.10 and stopped working in 2.6.11. This could
be changed by setting the default for the two new volumes to muted. I
don't know how this affects the issue with the docking station or the
bug that this is supposed to solve though.

[Mark Canter]

Yes, flipping back to the 2.6.10 kernel resolves the sound issue through
the docking station so that everything runs without incident. Though I'd
like to see/assist in resolving the issue for future releases :).

On Thu, 3 Mar 2005, Andrew Morton wrote:

> Mark Canter <mar...@vfxcomputing.com> wrote:
>>
>>
>> To close this issue out of the LKML and alsa-devel, a bug report has been
>> written.
>>
>> It appears to be an issue with the 'headphone jack sense' (as kde labels
>> it). The issue is in the way the 8x0 addresses the docking station/port
>> replicator's audio output jack. The mentioned quick fix does not work for
>> using the ds/pr audio output, but does resolve it for a user that is only
>> using headphones/internal speakers.
>
> But there was a behavioural change: applications which worked in 2.6.10
> don't work in 2.6.11, is that correct?
>
> If so, the best course of action is to change the kernel so those
> applications work again. Can that be done?
>

[Andrew Morton]

Mark Canter <mar...@vfxcomputing.com> wrote:
>
>
> To close this issue out of the LKML and alsa-devel, a bug report has been
> written.
>
> It appears to be an issue with the 'headphone jack sense' (as kde labels
> it). The issue is in the way the 8x0 addresses the docking station/port
> replicator's audio output jack. The mentioned quick fix does not work for
> using the ds/pr audio output, but does resolve it for a user that is only
> using headphones/internal speakers.

But there was a behavioural change: applications which worked in 2.6.10

don't work in 2.6.11, is that correct?

If so, the best course of action is to change the kernel so those
applications work again. Can that be done?

-

[Lee Revell]

On Thu, 2005-03-03 at 14:06 -0500, Mark Canter wrote:
> Correct, but if you want to use your headphones you would have to enable
> headphones on your mixer, which would negate your speaker output through
> your docking station's output. If you want to use the docking station
> speakers, you would have to disable the headphones in order to get the
> docking station speakers to work; no? If that is the case, then you would
> still have to enable/disable each time you wanted to change the direction
> of headphones/external speakers. Again, this is not the case under <=
> 2.6.10 where it works regardless of enabling/disabling headphones.
>

> I'd hate to rant and rave here under something that has worked under 2.4.x
> and <= 2.6.10. But this seems like a very un-userfriendly solution to
> something that has had no issues for quite some time. In that case, what
> deemed the change necessary? As far as I see the 8x0 driver added support
> for ICH7. I'm sure there's more to it than just that, I just haven't
> looked into it the rest of the way.

Because the change was needed to make someone else's hardware work.
It's a bug, bugs happen.

If you want to complain, complain to the hardware manufacturers, who
make devices where bit $foo means $bar in one hardware revision, and
$baz in the next, and don't give us sufficient documentation to sort out
the mess.

Lee

[Mark Canter]

Correct, but if you want to use your headphones you would have to enable
headphones on your mixer, which would negate your speaker output through
your docking station's output. If you want to use the docking station
speakers, you would have to disable the headphones in order to get the
docking station speakers to work; no? If that is the case, then you would
still have to enable/disable each time you wanted to change the direction
of headphones/external speakers. Again, this is not the case under <=
2.6.10 where it works regardless of enabling/disabling headphones.

I'd hate to rant and rave here under something that has worked under 2.4.x
and <= 2.6.10. But this seems like a very un-userfriendly solution to
something that has had no issues for quite some time. In that case, what
deemed the change necessary? As far as I see the 8x0 driver added support
for ICH7. I'm sure there's more to it than just that, I just haven't
looked into it the rest of the way.

[Lee Revell]

(I hope you don't mind me re-adding LKML because this illustrates an
important point)

On Thu, 2005-03-03 at 14:15 -0500, Mark Canter wrote:
> Seems like the Q/A process is kind of borked if the below tests are known
> but don't get applied before it gets released into the wild.

We will never be able to get 100% of these before they get out the door,
because the ALSA developers can't test on every possible hardware. And
the group of users who test ALSA CVS and ALSA releases before they go in
the kernel is small.

That being said, you are 100% right. It is widely acknowledged that the
release candidate process is broken. The solution is to fix the release
candidate process, so more people try the -rcs. This is the only way to
catch bugs like this before they get out. Please see the "release
numbering" thread for some proposed solutions.

[Jeff Garzik]

Lee Revell wrote:
> If you want to complain, complain to the hardware manufacturers, who
> make devices where bit $foo means $bar in one hardware revision, and
> $baz in the next, and don't give us sufficient documentation to sort out
> the mess.

That's not terribly productive.

Life is what it is. We deal with it.

Jeff

[Lee Revell]

On Fri, 2005-03-04 at 00:13 -0500, Jeff Garzik wrote:
> Lee Revell wrote:
> > If you want to complain, complain to the hardware manufacturers, who
> > make devices where bit $foo means $bar in one hardware revision, and
> > $baz in the next, and don't give us sufficient documentation to sort out
> > the mess.
>
> That's not terribly productive.
>
> Life is what it is. We deal with it.

That was actually my point. I guess I could have been a bit clearer...

Anyone who works with drivers knows that hardware manufacturers will
always do things like this. There is absolutely no point in complaining
about it, either to the vendor or on LKML. The only fix is to file a
good bug report so it can be fixed.

Lee

[Bill Davidsen]

Nish Aravamudan wrote:
> On Thu, 03 Mar 2005 13:51:40 +0100, Pierre Ossman <drzeu...@drzeus.cx> wrote:
>
>>I just upgraded to Linux 2.6.11 and the soundcard on my machine went
>>silent. All volume controls are correct and there are no errors
>>reported. But no sound coming from the speakers. And here's the kicker,
>>the headphones work fine!
>>2.6.10 still works so the bug appeared in one of the patches in between.
>>The sound card is the one integrated into intels mobile ICH4 chipset.
>
>
> There was some discussion of this on LKML a while ago. Are you sure
> you have disabled "Headphone Jack Sense" and "Line Jack Sense" in
> alsamixer?

Is there some option to alsamixer to get those to show up? There's no
such entry in the default display (FC3 w/ kernel.org 2.6.1[01]).

--
-bill davidsen (davi...@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

[Mark Canter]

Bill:

As I have been running through the kernel setting:

2.6.11/sound/pci/ac97/ac97_patch.c:

static const snd_kcontrol_new_t snd_ac97_ad1981x_jack_sense[] = {
AC97_SINGLE("Headphone Jack Sense", AC97_AD_JACK_SPDIF, 11, 1, 1),

Note the last "1" is originally "0" in the kernel. This might do it, but
the issue for me remains that the line-detect for line-out should turn off
the internal speakers (as it previously has). Instead I have line-out
working and internal speakers going. And, yes, the headphones still work.
All of this with 'headphone jack sense' enabled.

If you're not using line-out (out of a docking station) the above may work
for you. I tested plugging my speakers from the docking station into the
headphone jack and the interal speakers did cut off as expected.

mark

On Fri, 4 Mar 2005, Bill Davidsen wrote:

> Lee Revell wrote:
>> On Thu, 2005-03-03 at 13:46 -0500, Mark Canter wrote:
>>

>>> The same issue exists on a T42p (ICH4). Doesn't that kind of defeat the
>>> purpose? The thought of having to disable the headphone jack and reenable
>>> it each time is trivial considering you can go with the fact that sound
>>> did not require the sound system touched under <= 2.6.10.
>>
>>

>> You don't have to disable and re-enable it each time, if your system is
>> configured correctly then your mixer settings will be saved.
>

> I don't think you understand the problem. Saving the settings does help, you
> have to change the settings every time you switch from headphones to speaker.
> Assuming I follow the o.p. issue... alsamixer shows no "sense" settings for
> my ASUS laptop, and I have to boot 2.4 to get sound.

[Bill Davidsen]

Lee Revell wrote:
> On Thu, 2005-03-03 at 13:46 -0500, Mark Canter wrote:
>
>>The same issue exists on a T42p (ICH4). Doesn't that kind of defeat the
>>purpose? The thought of having to disable the headphone jack and reenable
>>it each time is trivial considering you can go with the fact that sound
>>did not require the sound system touched under <= 2.6.10.
>
>
> You don't have to disable and re-enable it each time, if your system is
> configured correctly then your mixer settings will be saved.

I don't think you understand the problem. Saving the settings does help,

you have to change the settings every time you switch from headphones to
speaker. Assuming I follow the o.p. issue... alsamixer shows no "sense"
settings for my ASUS laptop, and I have to boot 2.4 to get sound.

--
-bill davidsen (davi...@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

[Lee Revell]

On Fri, 2005-03-04 at 15:40 -0500, Bill Davidsen wrote:
> Lee Revell wrote:
> > On Thu, 2005-03-03 at 13:46 -0500, Mark Canter wrote:
> >
> >>The same issue exists on a T42p (ICH4). Doesn't that kind of defeat the
> >>purpose? The thought of having to disable the headphone jack and reenable
> >>it each time is trivial considering you can go with the fact that sound
> >>did not require the sound system touched under <= 2.6.10.
> >
> >
> > You don't have to disable and re-enable it each time, if your system is
> > configured correctly then your mixer settings will be saved.
>
> I don't think you understand the problem. Saving the settings does help,
> you have to change the settings every time you switch from headphones to
> speaker. Assuming I follow the o.p. issue... alsamixer shows no "sense"
> settings for my ASUS laptop, and I have to boot 2.4 to get sound.
>

Thanks, I understand it now. It looked like the same bug but there is
actually something else going on.

Lee

[Lee Revell]

On Fri, 2005-03-04 at 15:36 -0500, Bill Davidsen wrote:
> Nish Aravamudan wrote:
> > On Thu, 03 Mar 2005 13:51:40 +0100, Pierre Ossman <drzeu...@drzeus.cx> wrote:
> >
> >>I just upgraded to Linux 2.6.11 and the soundcard on my machine went
> >>silent. All volume controls are correct and there are no errors
> >>reported. But no sound coming from the speakers. And here's the kicker,
> >>the headphones work fine!
> >>2.6.10 still works so the bug appeared in one of the patches in between.
> >>The sound card is the one integrated into intels mobile ICH4 chipset.
> >
> >
> > There was some discussion of this on LKML a while ago. Are you sure
> > you have disabled "Headphone Jack Sense" and "Line Jack Sense" in
> > alsamixer?
>
> Is there some option to alsamixer to get those to show up? There's no
> such entry in the default display (FC3 w/ kernel.org 2.6.1[01]).
>

Does switching the view with F3 (Playback), F4 (Capture), F5 (All) and
scrolling all the way right help?

If that fails, does "amixer" list them?

Lee

[Pierre Ossman]

Pierre Ossman wrote:
> Andrew Morton wrote:
>
>> Mark Canter <mar...@vfxcomputing.com> wrote:
>>
>>
>>> To close this issue out of the LKML and alsa-devel, a bug report has
>>> been written.
>>>
>>> It appears to be an issue with the 'headphone jack sense' (as kde
>>> labels it). The issue is in the way the 8x0 addresses the docking
>>> station/port replicator's audio output jack. The mentioned quick fix
>>> does not work for using the ds/pr audio output, but does resolve it
>>> for a user that is only using headphones/internal speakers.
>>>
>>
>>
>> But there was a behavioural change: applications which worked in 2.6.10
>> don't work in 2.6.11, is that correct?
>>
>> If so, the best course of action is to change the kernel so those
>> applications work again. Can that be done?
>>
>>
>>
> Yes. Speakers worked in 2.6.10 and stopped working in 2.6.11. This could
> be changed by setting the default for the two new volumes to muted. I
> don't know how this affects the issue with the docking station or the
> bug that this is supposed to solve though.
>

It seems I spoke too soon. The defaults picked by the driver are
actually fine. It seems to be alsactl store/restore that did something
strange when coming from an older kernel.

[Lee Revell]

On Fri, 2005-03-04 at 22:16 +0100, Pierre Ossman wrote:
> Pierre Ossman wrote:
> > Andrew Morton wrote:
> >
> >> Mark Canter <mar...@vfxcomputing.com> wrote:
> >>
> >>
> >>> To close this issue out of the LKML and alsa-devel, a bug report has
> >>> been written.
> >>>
> >>> It appears to be an issue with the 'headphone jack sense' (as kde
> >>> labels it). The issue is in the way the 8x0 addresses the docking
> >>> station/port replicator's audio output jack. The mentioned quick fix
> >>> does not work for using the ds/pr audio output, but does resolve it
> >>> for a user that is only using headphones/internal speakers.
> >>>
> >>
> >>
> >> But there was a behavioural change: applications which worked in 2.6.10
> >> don't work in 2.6.11, is that correct?
> >>
> >> If so, the best course of action is to change the kernel so those
> >> applications work again. Can that be done?
> >>
> >>
> >>
> > Yes. Speakers worked in 2.6.10 and stopped working in 2.6.11. This could
> > be changed by setting the default for the two new volumes to muted. I
> > don't know how this affects the issue with the docking station or the
> > bug that this is supposed to solve though.
> >
>
> It seems I spoke too soon. The defaults picked by the driver are
> actually fine. It seems to be alsactl store/restore that did something
> strange when coming from an older kernel.
>

So is there a bug or not? Mark seems to be the only one affected.

It's important to follow up, because these so-called "ALSA regressions"
are generating bad press.

Lee

[Takashi Iwai]

At Fri, 04 Mar 2005 22:16:03 +0100,

Pierre Ossman wrote:
>
> Pierre Ossman wrote:
> > Andrew Morton wrote:
> >
> >> Mark Canter <mar...@vfxcomputing.com> wrote:
> >>
> >>
> >>> To close this issue out of the LKML and alsa-devel, a bug report has
> >>> been written.
> >>>
> >>> It appears to be an issue with the 'headphone jack sense' (as kde
> >>> labels it). The issue is in the way the 8x0 addresses the docking
> >>> station/port replicator's audio output jack. The mentioned quick fix
> >>> does not work for using the ds/pr audio output, but does resolve it
> >>> for a user that is only using headphones/internal speakers.
> >>>
> >>
> >>
> >> But there was a behavioural change: applications which worked in 2.6.10
> >> don't work in 2.6.11, is that correct?
> >>
> >> If so, the best course of action is to change the kernel so those
> >> applications work again. Can that be done?
> >>
> >>
> >>
> > Yes. Speakers worked in 2.6.10 and stopped working in 2.6.11. This could
> > be changed by setting the default for the two new volumes to muted. I
> > don't know how this affects the issue with the docking station or the
> > bug that this is supposed to solve though.
> >
>
> It seems I spoke too soon. The defaults picked by the driver are
> actually fine. It seems to be alsactl store/restore that did something
> strange when coming from an older kernel.

My guess is that kmix is the cuplrit.
kmix tends to turn on all mixer switches uncoditionally, and
saves/restores the mixer config by itself.

Look at /etc/asound.state whether it contains the value of "Headphone
Jack Sense" control true or false.

BTW, the default value of this control switch was fixed for ThinkPads
on ALSA tree since long time ago, but unfortunately the patch wasn't
accepted for 2.6.11...

Takashi

[Pierre Ossman]

Takashi Iwai wrote:

>>>Look at /etc/asound.state whether it contains the value of "Headphone
>>>Jack Sense" control true or false.
>>>
>>>
>>>
>>>

>>It saves the setting once I've been in 2.6.11. From an earlier kernel
>>there is no such entry.
>>
>>
>
>Of course, the earlier version didn't have this.
>
>And did you take a look at the latest content? What stands on it?
>Maybe you once saved a value wrongly corrected by any reason?
>
>
>
I'm not sure what you mean. In the 2.6.10 version the last entry is
'Stereo Mic'. In 2.6.11 there's 'Headphone Jack Sense' and 'Line Jack
Sense' following that.
From what I can tell every entry seems valid.

Rgds
Pierre

[Pierre Ossman]

Lee Revell wrote:

>So is there a bug or not? Mark seems to be the only one affected.
>
>It's important to follow up, because these so-called "ALSA regressions"
>are generating bad press.
>
>Lee
>
>
>

I can generate the error using the following procedure:

1. Boot in 2.6.10. Remove /etc/asound.conf and store the current mixer
settings.
2. Boot in 2.6.11 and let alsactl restore the mixer.

Provided the machine is powered down between each attempt this gives the
same result. 'Headphone Jack Sense' ends up not muted (which means that
the built-in speakers are dead).

I fail to find where FC saves/restores the mixer settings so I can't
test without it. There are commands in modprobe.conf but asound.conf
still gets updated when I remove these lines. So there must be some more
place[s] where alsactl gets called.

Rgds
Pierre

[Takashi Iwai]

At Mon, 07 Mar 2005 21:13:23 +0100,

Pierre Ossman wrote:
>
> Lee Revell wrote:
>
> >So is there a bug or not? Mark seems to be the only one affected.
> >
> >It's important to follow up, because these so-called "ALSA regressions"
> >are generating bad press.
> >
> >Lee
> >
> >
> >
> I can generate the error using the following procedure:
>
> 1. Boot in 2.6.10. Remove /etc/asound.conf and store the current mixer
> settings.
> 2. Boot in 2.6.11 and let alsactl restore the mixer.
>
> Provided the machine is powered down between each attempt this gives the
> same result. 'Headphone Jack Sense' ends up not muted (which means that
> the built-in speakers are dead).
>
> I fail to find where FC saves/restores the mixer settings so I can't
> test without it. There are commands in modprobe.conf but asound.conf
> still gets updated when I remove these lines. So there must be some more
> place[s] where alsactl gets called.

Usually it's called either in init script or in udev configuration.

Or, it's not set up via alsactl but by other apps (e.g. kmix). I'm
not sure whether GNOME does anything special in this regard, though.

Takashi

[Takashi Iwai]

At Mon, 07 Mar 2005 21:16:10 +0100,
Pierre Ossman wrote:

>
> Takashi Iwai wrote:
>
> >At Fri, 04 Mar 2005 22:16:03 +0100,
> >Pierre Ossman wrote:
> >
> >
> >>It seems I spoke too soon. The defaults picked by the driver are
> >>actually fine. It seems to be alsactl store/restore that did something
> >>strange when coming from an older kernel.
> >>
> >>
> >
> >My guess is that kmix is the cuplrit.
> >kmix tends to turn on all mixer switches uncoditionally, and
> >saves/restores the mixer config by itself.
> >
> >

> I use Gnome, not KDE so kmix is not an issue.

OK. (Then it might be a gnome mixer :)

> >Look at /etc/asound.state whether it contains the value of "Headphone
> >Jack Sense" control true or false.
> >
> >
> It saves the setting once I've been in 2.6.11. From an earlier kernel
> there is no such entry.

Of course, the earlier version didn't have this.

And did you take a look at the latest content? What stands on it?
Maybe you once saved a value wrongly corrected by any reason?

> >BTW, the default value of this control switch was fixed for ThinkPads
> >on ALSA tree since long time ago, but unfortunately the patch wasn't
> >accepted for 2.6.11...
> >
> >

> My machine is a hp/compaq, not a thinkpad, so I don't know if it would
> have any effect here.

The fix is not only for ThinkPads but for all machines with AD1981
codec and not known to work with "headphone jack" stuff.

[Takashi Iwai]

At Tue, 08 Mar 2005 02:10:06 +0100,

Pierre Ossman wrote:
>
> Takashi Iwai wrote:
>
> >>>Look at /etc/asound.state whether it contains the value of "Headphone
> >>>Jack Sense" control true or false.
> >>>
> >>>
> >>>
> >>>
> >>It saves the setting once I've been in 2.6.11. From an earlier kernel
> >>there is no such entry.
> >>
> >>
> >
> >Of course, the earlier version didn't have this.
> >
> >And did you take a look at the latest content? What stands on it?
> >Maybe you once saved a value wrongly corrected by any reason?
> >
> >
> >
> I'm not sure what you mean. In the 2.6.10 version the last entry is
> 'Stereo Mic'. In 2.6.11 there's 'Headphone Jack Sense' and 'Line Jack
> Sense' following that.
> From what I can tell every entry seems valid.

My question is its 'value'. The entry in /etc/asound.state should
have a boolean value.

Let me repeat the explanation of the situation:

The existence of 'Headphone Jack Sense' and 'Line-in Jack Sense'
controls themselves are not the problem. If they are set off, the
behavior of the driver must be identical with the older version.
No regression. The patch I mentionted turns off them as default unless
the device is known to work. But the controls still exist, and you
can change them afterward manually.

So, the solution is once to turn off these controls via a mixer and
save the state via alsactl (usually the system does at shutdown), so
that the correct states are restored at the next reboot. That's why I
asked you - to check the saved status of these controls.

If the correct values are saved there and still the problem exists,
someone else must have changed the mixer status. For example, KDE
(kmix) seems to set up the mixer status by itself, and does not always
correctly. That was my suspect. I don't know GNOME does something
like that, too.

Takashi

[Pierre Ossman]

Takashi Iwai wrote:

>At Tue, 08 Mar 2005 02:10:06 +0100,
>Pierre Ossman wrote:
>
>
>>Takashi Iwai wrote:
>>
>>
>>
>>>>>Look at /etc/asound.state whether it contains the value of "Headphone
>>>>>Jack Sense" control true or false.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>It saves the setting once I've been in 2.6.11. From an earlier kernel
>>>>there is no such entry.
>>>>
>>>>
>>>>
>>>>
>>>Of course, the earlier version didn't have this.
>>>
>>>And did you take a look at the latest content? What stands on it?
>>>Maybe you once saved a value wrongly corrected by any reason?
>>>
>>>
>>>
>>>
>>>
>>I'm not sure what you mean. In the 2.6.10 version the last entry is
>>'Stereo Mic'. In 2.6.11 there's 'Headphone Jack Sense' and 'Line Jack
>>Sense' following that.
>> From what I can tell every entry seems valid.
>>
>>
>
>My question is its 'value'. The entry in /etc/asound.state should
>have a boolean value.
>
>Let me repeat the explanation of the situation:
>
>The existence of 'Headphone Jack Sense' and 'Line-in Jack Sense'
>controls themselves are not the problem. If they are set off, the
>behavior of the driver must be identical with the older version.
>No regression. The patch I mentionted turns off them as default unless
>the device is known to work. But the controls still exist, and you
>can change them afterward manually.
>
>
>

That patch is probably what's missing then. Everything works fine here
now that I've turned of the 'Sense' channels. And there is no problem
retaining that value each reboot. The issue was that things stopped
working during the upgrade and the solution was far from obvious.

So I'm not having any problems with this change anymore. I was just
thinking about the other poor sods who are upgrading to 2.6.11 =)

Rgds
Pierre

[Mark Canter]

I think I've gone through every possible value here from asound.state to
each setting in KDE itself. Still, the only sound that works is the one
coming from line-out, without the port replicator, no sound exists
whatsoever. Both of the below controls are set to false in asound.state
and cooresponding KDE settings in kmix.

I think the concern becomes though, regardless of what kde was doing after
the fact, this condition didn't exits in <= 2.6.10 when no other
applications where changed around it.

[Lee Revell]

On Tue, 2005-03-08 at 20:53 -0500, Mark Canter wrote:
> I think I've gone through every possible value here from asound.state to
> each setting in KDE itself. Still, the only sound that works is the one
> coming from line-out, without the port replicator, no sound exists
> whatsoever. Both of the below controls are set to false in asound.state
> and cooresponding KDE settings in kmix.
>
> I think the concern becomes though, regardless of what kde was doing after
> the fact, this condition didn't exits in <= 2.6.10 when no other
> applications where changed around it.

If you revert both the attached patches, does it work?

They are against alsa CVS, so to back these patches out from your 2.6.11
tree do this:

cd linux-2.6.11/sound/pci/ac97
patch -p0 -R < ac97-2.patch
patch -p0 -R < ac97.patch

Lee