Message-ID: <s5h39b51807.wl%tiwai@suse.de>
Date:	Tue, 24 Jan 2012 15:37:44 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Joseph Parmelee <jparmele@...dbear.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Sound broken in 3.2.0 and 3.2.1

At Tue, 24 Jan 2012 08:31:21 -0600 (CST),
Joseph Parmelee wrote:
> 
> 
> 
> 
> On Tue, 24 Jan 2012, Takashi Iwai wrote:
> 
> > Hm, could you run alsa-info.sh now?  The proc codec file isn't
> > comprehensive and lacks of many info.  Also, if you get alsa-info.sh
> > outputs, please use attachments.  It's more handy to have them in
> > separate files than in embedded texts.
> >
> 
> Attached please find result of alsa-info.sh run on 3.2.1 AFTER the startup
> file has been run.  As I mentioned before, this is a production system and I
> have had to take it down too many times already in dealing with this
> problem.  This regression is not to the test version of linux, where one
> expects to play adventure, but to the supposedly stable version.

Thanks.

> >> To "fix" 3.2.1, I made the following changes to the system startup file:
> >>
> >> I discovered that the PCM control, though absent in 3.2.1 on loading the
> >> sound modules with
> >>
> >> modprobe snd_hda_intel
> >> modprobe snd_pcm_oss
> >>
> >> appears after aplay is called on any sound file.  Also the main playback
> >> volume control has been shifted from "PCM" to "Front" which can be set with:
> >>
> >> /usr/bin/amixer sset "Front",0 64,64
> >
> > The main volume control is always "Master".  It wasn't changed.  "PCM"
> > is an additional control.  Now the driver supports multi-channel
> > playback, thus "PCM" control is split to each channel.
> >
> 
> The key point here is that the FRONT control is new and initialized to zero,
> and the PCM control for the channel being used does not appear until after
> aplay is run from the command line.  Prior to that, PCM is invisible and
> cannot be reached by any of the mixers.  Moreover, it is not activated by
> mplayer which is what caused our immediate problem; aplay has to be run from
> the command line on some sound file.

It's because "PCM" volume is implemented in alsa-lib softvol plugin.
This isn't the thing handled in the driver at all.

> As you say the MASTER control (mono) affects everything.  I should have said
> the new FRONT control (stereo, initialized to zero) appears to affect all
> playback (at least through the channel we use) and there is still no control
> named MASTER PLAYBACK visible, though it now shows in the output of alsactl
> initialized to max.

This is odd.  If alsactl shows the Master volume, the mixer must show
it too.

>  There is only one PCM control visible (after aplay is
> run) which affects play, aplay, and mplayer.  There are probably more
> controls that are not yet visible, particularly those involving capture
> which we don't use.  Some of these are likely also initialized to zero and
> will cause trouble for those trying to use them.  As I mentioned, this is a
> kludge for our system developed by playing adventure and is not claimed to
> be general in any sense.
> 
> > Usually alsactl should initialize such uninitialized volumes
> > appropriately at boot time, but this didn't seem to work in your
> > case.  Maybe it's a bug that was recently fixed in alsa-utils
> > package.
> >
> 
> How is that supposed to work the first time alsactl is called?

"alsactl init" initializes the volumes to some audible values.  Then
it tries to restore the values from the last saved state file.

>  We rely
> ultimately on the sound modules appropriately initializing the controls on
> loading. 

No, it's never been so.  The driver is "appropriately" initializing to
the safe value -- i.e. usually the muted status.


Takashi
--
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/

Powered by blists - more mailing lists