linux-kernel - Re: ALSA problems with 2.6.18-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200608092307.27615.s0348365@sms.ed.ac.uk>
Date:	Wed, 9 Aug 2006 23:07:27 +0100
From:	Alistair John Strachan <s0348365@....ed.ac.uk>
To:	Lee Revell <rlrevell@...-job.com>
Cc:	Gene Heskett <gene.heskett@...izon.net>,
	linux-kernel@...r.kernel.org, Andrew Benton <b3nt@...nline.co.uk>,
	Takashi Iwai <tiwai@...e.de>,
	alsa-devel <alsa-devel@...ts.sourceforge.net>
Subject: Re: ALSA problems with 2.6.18-rc3

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/