Message-ID: <alpine.LNX.2.00.1201240614520.1825@bruno>
Date:	Tue, 24 Jan 2012 08:31:21 -0600 (CST)
From:	Joseph Parmelee <jparmele@...dbear.com>
To:	Takashi Iwai <tiwai@...e.de>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Sound broken in 3.2.0 and 3.2.1




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.

>> 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.

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.  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?  We rely
ultimately on the sound modules appropriately initializing the controls on
loading.  If there is now a dependence on alsactl to initialize, as well as
save/restore the sound state, that should be clearly documented and/or a
suitable initial asound.state provided for each module.

As I mentioned, I first rebuilt everything using the latest released
versions to avoid just this scenario.  If there is a fix in alsa-utils for
this which is still stuck in the repository, please see that it is released
immediately.


Yours,
Joseph Parmelee
View attachment "alsa-info.txt.hNvkGCnft7" of type "TEXT/PLAIN" (34897 bytes)

Powered by blists - more mailing lists