Hello World,
I use the optical digital output from my computer and normally it works
well. However, with a 2.6.18-rc* kernel I have to use alsamixer to get
any output from it. I tweak the levels till it's working and use alsactl
store to save it. Normally, when I reboot it's enough to have a
bootscript run alsactl restore and it should work, but as I said, with
a 2.6.18-rc* kernel it doesn't. Every time I have to use alsamixer to
change the <IEC958 P> setting to A/D Conv and then back to AC-Link again
to get the diode to come on and start sending a signal to the amplifier.
And the problems don't stop there. At first it sounds fine but after a
few minutes it starts to develop a harsh, tinny, metallic, distorted
quality and it becomes unlistenable.
According to alsamixer v1.0.11, the card is an Intel ICH5 and the chip
is an Analog Devices AD1981B
Andy
On Tue, 2006-08-08 at 21:28 +0100, Andrew Benton wrote:
> Hello World,
> I use the optical digital output from my computer and normally it works
> well. However, with a 2.6.18-rc* kernel I have to use alsamixer to get
> any output from it. I tweak the levels till it's working and use alsactl
> store to save it. Normally, when I reboot it's enough to have a
> bootscript run alsactl restore and it should work, but as I said, with
> a 2.6.18-rc* kernel it doesn't. Every time I have to use alsamixer to
> change the <IEC958 P> setting to A/D Conv and then back to AC-Link again
> to get the diode to come on and start sending a signal to the amplifier.
> And the problems don't stop there. At first it sounds fine but after a
> few minutes it starts to develop a harsh, tinny, metallic, distorted
> quality and it becomes unlistenable.
>
> According to alsamixer v1.0.11, the card is an Intel ICH5 and the chip
> is an Analog Devices AD1981B
Please try to identify the change that introduced the regression. What
was the last kernel/ALSA version that worked correctly?
Lee
At Tue, 08 Aug 2006 21:28:21 +0100,
Andrew Benton wrote:
>
> Hello World,
> I use the optical digital output from my computer and normally it works
> well. However, with a 2.6.18-rc* kernel I have to use alsamixer to get
> any output from it. I tweak the levels till it's working and use alsactl
> store to save it. Normally, when I reboot it's enough to have a
> bootscript run alsactl restore and it should work, but as I said, with
> a 2.6.18-rc* kernel it doesn't. Every time I have to use alsamixer to
> change the <IEC958 P> setting to A/D Conv and then back to AC-Link again
> to get the diode to come on and start sending a signal to the amplifier.
> And the problems don't stop there. At first it sounds fine but after a
> few minutes it starts to develop a harsh, tinny, metallic, distorted
> quality and it becomes unlistenable.
>
> According to alsamixer v1.0.11, the card is an Intel ICH5 and the chip
> is an Analog Devices AD1981B
There is no influential change in intel8x0 and ac97 stuff between
2.6.17 and 2.6.18. If it worked with 2.6.17, it must be something
else.
Takashi
Lee Revell wrote:
> Please try to identify the change that introduced the regression. What
> was the last kernel/ALSA version that worked correctly?
The change happened between 2.6.17 and 2.6.18-rc1. Specifically,
2.6.17-git4 works and 2.6.17-git5 doesn't.
Andy
On Wed, 2006-08-09 at 17:30 +0100, Andrew Benton wrote:
> Lee Revell wrote:
> > Please try to identify the change that introduced the regression. What
> > was the last kernel/ALSA version that worked correctly?
>
> The change happened between 2.6.17 and 2.6.18-rc1. Specifically,
> 2.6.17-git4 works and 2.6.17-git5 doesn't.
Takashi-san,
Does this help at all? Many users are reporting that sound broke with
2.6.18-rc*.
Lee
On Wed, 2006-08-09 at 12:35 -0400, Lee Revell wrote:
> On Wed, 2006-08-09 at 17:30 +0100, Andrew Benton wrote:
> > Lee Revell wrote:
> > > Please try to identify the change that introduced the regression. What
> > > was the last kernel/ALSA version that worked correctly?
> >
> > The change happened between 2.6.17 and 2.6.18-rc1. Specifically,
> > 2.6.17-git4 works and 2.6.17-git5 doesn't.
>
> Takashi-san,
>
> Does this help at all? Many users are reporting that sound broke with
> 2.6.18-rc*.
Fwiw, 2.6.18-rc1 works on arm (pxa2xx). Maybe this is related to another
subsystem not found on arm.
Liam
On Wednesday 09 August 2006 12:35, Lee Revell wrote:
>On Wed, 2006-08-09 at 17:30 +0100, Andrew Benton wrote:
>> Lee Revell wrote:
>> > Please try to identify the change that introduced the regression.
>> > What was the last kernel/ALSA version that worked correctly?
>>
>> The change happened between 2.6.17 and 2.6.18-rc1. Specifically,
>> 2.6.17-git4 works and 2.6.17-git5 doesn't.
>
>Takashi-san,
>
>Does this help at all? Many users are reporting that sound broke with
>2.6.18-rc*.
>
>Lee
>
Takashi-san's suggestion earlier today of running an "alsactl -F restore"
seems to have fixed all those diffs right up, I now have good sound with
an emu10k1 using an audigy 2 as card-0, running kernel-2.6.18-rc4.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Wed, 2006-08-09 at 14:17 -0400, Gene Heskett wrote:
> On Wednesday 09 August 2006 12:35, Lee Revell wrote:
> >On Wed, 2006-08-09 at 17:30 +0100, Andrew Benton wrote:
> >> Lee Revell wrote:
> >> > Please try to identify the change that introduced the regression.
> >> > What was the last kernel/ALSA version that worked correctly?
> >>
> >> The change happened between 2.6.17 and 2.6.18-rc1. Specifically,
> >> 2.6.17-git4 works and 2.6.17-git5 doesn't.
> >
> >Takashi-san,
> >
> >Does this help at all? Many users are reporting that sound broke with
> >2.6.18-rc*.
> >
> >Lee
> >
> Takashi-san's suggestion earlier today of running an "alsactl -F restore"
> seems to have fixed all those diffs right up, I now have good sound with
> an emu10k1 using an audigy 2 as card-0, running kernel-2.6.18-rc4.
Distros should probably be using this as a default. Otherwise, simply
adding a new mixer control will cause restoring mixer settings to fail.
Lee
On Wednesday 09 August 2006 16:41, Lee Revell wrote:
[...]
>> >Takashi-san,
>> >
>> >Does this help at all? Many users are reporting that sound broke with
>> >2.6.18-rc*.
>> >
>> >Lee
>>
>> Takashi-san's suggestion earlier today of running an "alsactl -F
>> restore" seems to have fixed all those diffs right up, I now have good
>> sound with an emu10k1 using an audigy 2 as card-0, running
>> kernel-2.6.18-rc4.
>
>Distros should probably be using this as a default. Otherwise, simply
>adding a new mixer control will cause restoring mixer settings to fail.
>
>Lee
I already have the 'alsactl restore' in my rc.local. Would there be any
harm in just adding the -F to that invocation, or will that just restore
it to a 'default' condition always. Seems like it would, canceling
anything you have done & then did an 'alsactl store' to save..
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Wed, 2006-08-09 at 16:51 -0400, Gene Heskett wrote:
> On Wednesday 09 August 2006 16:41, Lee Revell wrote:
> [...]
> >> >Takashi-san,
> >> >
> >> >Does this help at all? Many users are reporting that sound broke with
> >> >2.6.18-rc*.
> >> >
> >> >Lee
> >>
> >> Takashi-san's suggestion earlier today of running an "alsactl -F
> >> restore" seems to have fixed all those diffs right up, I now have good
> >> sound with an emu10k1 using an audigy 2 as card-0, running
> >> kernel-2.6.18-rc4.
> >
> >Distros should probably be using this as a default. Otherwise, simply
> >adding a new mixer control will cause restoring mixer settings to fail.
> >
> >Lee
>
> I already have the 'alsactl restore' in my rc.local. Would there be any
> harm in just adding the -F to that invocation, or will that just restore
> it to a 'default' condition always. Seems like it would, canceling
> anything you have done & then did an 'alsactl store' to save..
>
That's what I was suggesting - just add -F to the alsactl restore in
your init script. It won't restore it to a default state - the only
difference is that it will do a better job restoring your mixer state if
new controls are added by a driver update.
alsactl --help:
-F,--force try to restore the matching controls as much as
possible
Lee
On Wednesday 09 August 2006 21:57, Lee Revell wrote:
> On Wed, 2006-08-09 at 16:51 -0400, Gene Heskett wrote:
[snip]
> > I already have the 'alsactl restore' in my rc.local. Would there be any
> > harm in just adding the -F to that invocation, or will that just restore
> > it to a 'default' condition always. Seems like it would, canceling
> > anything you have done & then did an 'alsactl store' to save..
>
> That's what I was suggesting - just add -F to the alsactl restore in
> your init script. It won't restore it to a default state - the only
> difference is that it will do a better job restoring your mixer state if
> new controls are added by a driver update.
>
> alsactl --help:
>
> -F,--force try to restore the matching controls as much as
> possible
I assume there are drawbacks to such an option, since whatever method is used
to "force" the control may make a mistake if similarly named controls are
renamed.
Personally, I think the correct approach would be to have more sensible
default values. Having the External Amplifier default off when it cripples
analogue output on emu10k1, and has no effect on digital output, seems rather
weird. Also, I never really understood the rationale for the "all zeros"
mixer default. Why not 50%?
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Wed, 2006-08-09 at 22:22 +0100, Alistair John Strachan wrote:
> On Wednesday 09 August 2006 21:57, Lee Revell wrote:
> > On Wed, 2006-08-09 at 16:51 -0400, Gene Heskett wrote:
> [snip]
> > > I already have the 'alsactl restore' in my rc.local. Would there be any
> > > harm in just adding the -F to that invocation, or will that just restore
> > > it to a 'default' condition always. Seems like it would, canceling
> > > anything you have done & then did an 'alsactl store' to save..
> >
> > That's what I was suggesting - just add -F to the alsactl restore in
> > your init script. It won't restore it to a default state - the only
> > difference is that it will do a better job restoring your mixer state if
> > new controls are added by a driver update.
> >
> > alsactl --help:
> >
> > -F,--force try to restore the matching controls as much as
> > possible
>
> I assume there are drawbacks to such an option, since whatever method is used
> to "force" the control may make a mistake if similarly named controls are
> renamed.
>
> Personally, I think the correct approach would be to have more sensible
> default values. Having the External Amplifier default off when it cripples
> analogue output on emu10k1, and has no effect on digital output, seems rather
> weird.
It's impossible to predict the effect of some mixer controls across the
wide range of hardware that ALSA supports. What makes sound work on one
machine is likely to break it on another.
> Also, I never really understood the rationale for the "all zeros"
> mixer default. Why not 50%?
>
This is policy and policy belongs in userspace. Distros are free to
ship with any default mixer settings they choose.
Lee
On Wednesday 09 August 2006 22:34, Lee Revell wrote:
> On Wed, 2006-08-09 at 22:22 +0100, Alistair John Strachan wrote:
> > On Wednesday 09 August 2006 21:57, Lee Revell wrote:
> > > On Wed, 2006-08-09 at 16:51 -0400, Gene Heskett wrote:
> >
> > [snip]
> >
> > > > I already have the 'alsactl restore' in my rc.local. Would there be
> > > > any harm in just adding the -F to that invocation, or will that just
> > > > restore it to a 'default' condition always. Seems like it would,
> > > > canceling anything you have done & then did an 'alsactl store' to
> > > > save..
> > >
> > > That's what I was suggesting - just add -F to the alsactl restore in
> > > your init script. It won't restore it to a default state - the only
> > > difference is that it will do a better job restoring your mixer state
> > > if new controls are added by a driver update.
> > >
> > > alsactl --help:
> > >
> > > -F,--force try to restore the matching controls as much as
> > > possible
> >
> > I assume there are drawbacks to such an option, since whatever method is
> > used to "force" the control may make a mistake if similarly named
> > controls are renamed.
> >
> > Personally, I think the correct approach would be to have more sensible
> > default values. Having the External Amplifier default off when it
> > cripples analogue output on emu10k1, and has no effect on digital output,
> > seems rather weird.
>
> It's impossible to predict the effect of some mixer controls across the
> wide range of hardware that ALSA supports. What makes sound work on one
> machine is likely to break it on another.
However, ALSA _has_ defaults for these controls, which I believe are
usually "off" or "zero". All I'm suggesting is that these defaults are
plainly suboptimal for emu10k1, and probably other cards to which this
statement simply does not apply. Shipping defaults is one thing, but shipping
useless defaults is quite another. We have policy all over the kernel for
providing "sane defaults" e.g. filesystem mount options.
> > Also, I never really understood the rationale for the "all zeros"
> > mixer default. Why not 50%?
>
> This is policy and policy belongs in userspace. Distros are free to
> ship with any default mixer settings they choose.
True, I suppose if the mixers aren't even vaguely compatible across
hardware, "zero" is your best bet. I still see people reporting bugs (such as
this) where the distro has failed them. -F is not a complete solution.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Wed, 2006-08-09 at 23:07 +0100, Alistair John Strachan wrote:
> > It's impossible to predict the effect of some mixer controls across
> the
> > wide range of hardware that ALSA supports. What makes sound work on
> one
> > machine is likely to break it on another.
>
> However, ALSA _has_ defaults for these controls, which I believe are
> usually "off" or "zero". All I'm suggesting is that these defaults are
> plainly suboptimal for emu10k1, and probably other cards to which this
> statement simply does not apply. Shipping defaults is one thing, but
> shipping useless defaults is quite another. We have policy all over
> the kernel for providing "sane defaults" e.g. filesystem mount
> options.
I think muted is a sane default - the only sane default. Otherwise you
could damage speakers or hearing. Also many devices will be noisier if
unused inputs are enabled. Is it really that hard for users to unmute
the mixer or for distros to create their own config?
Also, analog output on my emu10k1 works perfectly with "External
Amplifier" disabled.
Lee
On Wednesday 09 August 2006 23:11, Lee Revell wrote:
> On Wed, 2006-08-09 at 23:07 +0100, Alistair John Strachan wrote:
[snip]
> > However, ALSA _has_ defaults for these controls, which I believe are
> > usually "off" or "zero". All I'm suggesting is that these defaults are
> > plainly suboptimal for emu10k1, and probably other cards to which this
> > statement simply does not apply. Shipping defaults is one thing, but
> > shipping useless defaults is quite another. We have policy all over
> > the kernel for providing "sane defaults" e.g. filesystem mount
> > options.
>
> I think muted is a sane default - the only sane default. Otherwise you
> could damage speakers or hearing. Also many devices will be noisier if
> unused inputs are enabled. Is it really that hard for users to unmute
> the mixer or for distros to create their own config?
I think this argument is mostly deflated by the fact that other
multimedia-centric operating systems do not ship with controls muted. If
hardware is detected, all sliders are set to 50%. I think this is superior.
As you pointed out, it probably is best left to distros. I just can't help
thinking that there might be some scope for improving the default state of
boolean tunables, even if sliders are left at zero.
> Also, analog output on my emu10k1 works perfectly with "External
> Amplifier" disabled.
Interesting, evidence in your favour. It does not work here. It also did not
work on the AC'97 in my HP NC6000, which also has External something-or-other
and which also defaulted to "off".
Took some figuring out. :-)
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Wed, 2006-08-09 at 23:28 +0100, Alistair John Strachan wrote:
> I think this argument is mostly deflated by the fact that other
> multimedia-centric operating systems do not ship with controls muted.
> If hardware is detected, all sliders are set to 50%. I think this is
> superior.
The developers audio drivers for other operating systems have full
access to the documentation of all the hardware they support, so it's
possible for them to establish "working" defaults for every device.
Lee
On Wednesday 09 August 2006 16:57, Lee Revell wrote:
>On Wed, 2006-08-09 at 16:51 -0400, Gene Heskett wrote:
>> On Wednesday 09 August 2006 16:41, Lee Revell wrote:
>> [...]
>>
>> >> >Takashi-san,
>> >> >
>> >> >Does this help at all? Many users are reporting that sound broke
>> >> > with 2.6.18-rc*.
>> >> >
>> >> >Lee
>> >>
>> >> Takashi-san's suggestion earlier today of running an "alsactl -F
>> >> restore" seems to have fixed all those diffs right up, I now have
>> >> good sound with an emu10k1 using an audigy 2 as card-0, running
>> >> kernel-2.6.18-rc4.
>> >
>> >Distros should probably be using this as a default. Otherwise, simply
>> >adding a new mixer control will cause restoring mixer settings to
>> > fail.
>> >
>> >Lee
>>
>> I already have the 'alsactl restore' in my rc.local. Would there be
>> any harm in just adding the -F to that invocation, or will that just
>> restore it to a 'default' condition always. Seems like it would,
>> canceling anything you have done & then did an 'alsactl store' to
>> save..
>
>That's what I was suggesting - just add -F to the alsactl restore in
>your init script. It won't restore it to a default state - the only
>difference is that it will do a better job restoring your mixer state if
>new controls are added by a driver update.
>
>alsactl --help:
>
> -F,--force try to restore the matching controls as much as
>possible
>
>Lee
Great, Lee, thanks. That also gave me a good excuse to expand the
operating $PATH for rc.local, recent heyu changes seem to have killed my
restoration of the config that existed after cron made the last change in
config.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
At Wed, 9 Aug 2006 23:28:47 +0100,
Alistair John Strachan wrote:
>
> > Also, analog output on my emu10k1 works perfectly with "External
> > Amplifier" disabled.
>
> Interesting, evidence in your favour. It does not work here. It also did not
> work on the AC'97 in my HP NC6000, which also has External something-or-other
> and which also defaulted to "off".
The external amplifier is on as default in the driver level.
There must be something else that took off.
Takashi
At Wed, 09 Aug 2006 12:35:32 -0400,
Lee Revell wrote:
>
> On Wed, 2006-08-09 at 17:30 +0100, Andrew Benton wrote:
> > Lee Revell wrote:
> > > Please try to identify the change that introduced the regression. What
> > > was the last kernel/ALSA version that worked correctly?
> >
> > The change happened between 2.6.17 and 2.6.18-rc1. Specifically,
> > 2.6.17-git4 works and 2.6.17-git5 doesn't.
>
> Takashi-san,
>
> Does this help at all? Many users are reporting that sound broke with
> 2.6.18-rc*.
Did you get so many bugreports as 2.6.18 regression? AFAIK, I had two
on LKML, and both of them are no serious problem.
Takashi