[GRLUG] strange audio levels problem

[Michael Mol]

On Tue, Jun 21, 2011 at 2:25 PM, John-Thomas Richards <jtr at jrichards.org> wrote:
> On Tue, Jun 21, 2011 at 01:11:57PM -0400, Michael Mol wrote:
>> > On Tue, Jun 21, 2011 at 6:27 AM, John-Thomas Richards <jtr at jrichards.org> wrote:
>> > I store the levels as root.  This box is also running PulseAudio.  The
>> > PulseAudio level is also often muted and at a low level (20 or 25 or
>> > 40).  Any ideas?  Sound just seems to be far too complicated these days.
>> > This almost (almost!) makes me wish for the OSS days.
>>
>> 'alsactl store' will save your sound settings so that they get
>> restored on bootup. That's reasonable and good.
>>
>> Your problem is that PulseAudio is a per-user system, whereas ALSA is
>> system-wide. Here's what's most likely going on:
>
> This is helpful.
>
>> 1) Your system enters its init sequence
>> 2) Your system restores the ALSA settings saved by alsactl.
>> 3) You log in
>> 4) The first app to access PulseAudio (either directly or via the
>> ALSA->Pulse wrapper library) will spawn the PA daemon.
>> 5) The PA daemon will adjust its internal mixer levels, and the ALSA
>> levels, as needed in order to satisfy whatever requests are made of
>> it.
>>
>> Step 2 is where things start to go wrong, step 5 is where they're
>> going to go *really* wrong. In general, you're going to want ALSA
>> configured to its maximum clean volume output. (For my sound chipset,
>> this means loading up alsamixer and adjusting each level until each
>> gain level reads '0').
>>
>> Once ALSA is configured to a good normalized baseline at system start,
>> your desktop session's sound daemon should behave better.
>
> I've adjusted the gain levels to 0 and stored them.  I'm still getting
> very strange and seemingly random levels.  I adjusted the levels and
> restarted X and rebooted a number of times.  Here are my levels after
> these restarts:  (Master | Speaker | PCM | Pulse)
>
>  99  |  94  | 100/mute |  85
>  91  |  94  |  99      |   9
>  0  | 100  | 100      |   8
>  0  |  94  | 100      |   8
>  0  |  94  | 100      |   9
> 100  |   0  | 100      | 100
>  3  |   0  |  98      |   9
>
> If the Pulse levels are being adjusted at Step 5, I cannot figure out
> what is accessing it.  I removed the sound applet from Cairo-dock (I'm
> running Openbox) and have no sound apps loading at launch.  It seems
> that if something is adjusting the levels it would do so consistently.
> To rule out Openbox as the culprit I restarted X into GNOME a couple
> times.  Same results (random).

That they're random seems very, very strange. That almost feels like
there's an uninitialized variable somewhere that's getting used in
calculating what to set levels to. Either that, or there are multiple
mixer-aware apps trying to restore sound preferences at the same time,
and they're not being brought up in a consistent sequence.

One thing to try:

Switch to using a custom X session for some diagnostics. Rather than
launching a full wm of any kind, just launch xterm. (Not konsole or
gnome-terminal or anything like that)

If Pulse is running with the ALSA hook enabled, then any app which
accesses ALSA for playback will launch Pulse, assuming Pulse has its
configuration cookie lodged with your running X session. Once you boot
into an X session which only has an xterm, you should be in as clean
an X environment as is possible. Run 'ps' and verify the Pulse daemon
isn't running. Now use alsamixer to check your levels.

1) Run ps and verify the Pulse daemon isn't running.
1a) If it is running, then something must have launched it prior to
your user session launching, and left it up. This is bad; The
PulseAudio folks strongly disrecommend using system-wide Pulse
daemons, for security reasons. I also don't know how to go much
farther in checking Pulse configurations in that kind of a setup.
1b) If it is not running, use alsamixer to check your card's audio
level. (Since I have Pulse handle ALSA apps, and have the Pulse
wrapper as my default sound device, I generally have to specify the
card using something like 'alsamixer -c0')
1b1) If your levels are where you recall them being from having used
alsactl-store, then, well, good. That means the problem more likely
rests with conflicting apps or applets being launched as part of your
user session.
1b2) If not, try having alsactl restore the values that it believes
were saved. Check those.
1b2a)If those aren't what you expect, then you've probably got
something in your shutdown cycle changing your ALSA settings and
storing them.
1b2b)If alsactl's restore gave the values you expected, then the
problem is between your login and your bootup. Some time in your init
cycle between the first alsactl restore and when you got your desktop
session (here, I'd wager the problem sits with xdm, kdm, gdm, whatever
you're using) is where things got messed up.

>
>> Two good links to go over if you're running Pulse, regardless of what
>> distro you're using:
>> https://wiki.archlinux.org/index.php/PulseAudio
>> http://www.pulseaudio.org/wiki/PerfectSetup
>
> These are good resources.  Unfortunately, I cannot find an answer to my
> problem.  The closest I found is in the second article that suggests
> running alsamixer to unmute sound.  I've already been doing that; I want
> to avoid having to do so.

Yeah, I hear you. I was stuck in a similar boat for a while earlier
this year. I discovered that if I visited a website which used flash
prior to using some other sound app (such as launching pavu-control),
then Flash would latch on to OSS. I had to switch to setting up an
ALSA device for pulse, and made that device default, and that helped.
Between that and learning more about the apps I was using, I got
things stable. The greatest annoyances I've had since are discovering
apps I want to use which *only* support OSS.

Then I switched to Gentoo+KDE a month or so ago, and Pulse worked
cleanly out of the box.

-- 
:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.