[gentoo-user] asound.state bug? Can anyone else reproduce this, please?

[gentoo-user] asound.state bug? Can anyone else reproduce this, please?

[Stroller]

Can anyone reproduce this, please?

The following steps conclude with a reboot:

1) `aplay -vv SomeFile.wav` - listen to some banging new tunes and satisfy yourself that your speakers and ears are working. Skip this step if you're already satisfied that your speakers are audible and that sound issues from them ok. 

2) Backup current alsa state - `/etc/init.d/alsasound save && cp /var/lib/alsa/asound.state ~/asound.state.bu`

3) Stop /etc/init.d/alsasound and remove it from the default run-level - `/etc/init.d/alsasound stop && rc-update del alsasound default`

4) Sound is still working, right? Now open `alsamixer` and mute it; ideal is to mute all channels thoroughly (use the left and right arrow keys to navigate channels, the M key to mute, the escape key to exit).

5) Run `/etc/init.d/alsasound save`

6) Reboot the system.

Afte the reboot, is the sound muted, please? 

Here it is, and I don't think it should be, because I think that should be restored by the /etc/init.d/alsasound script, which has a RESTORE_ON_START option in its conf.d file and which was removed from the default runlevel in step (3). We can establish that it's not running with `/etc/init.d/alsasound status`

I'm also seeing that maybe alsa's default state is muted, so that the muted state would be correct even if the sound state is not being restored. That's fine - restore the previous backup of sound from when audio was playing (`cp ~/asound.state.bu /var/lib/alsa/asound.state`) and reboot the system. Now the unmuted state is restored and you can listen to your music without starting /etc/init.d/alsasound.

I'm happy to elaborate on the little more I know about this stuff, if there's someone who can tell me that yes, they're seeing this, too, and yes, this is *not* the expected behaviour. Right now I'm still wondering if I'm doing something wrong.

This system is ~amd64, baselayout 2.1.

Stroller.

[gentoo-user] Re: asound.state bug? Can anyone else reproduce this, please?

[walt]

On 05/07/2012 01:40 PM, Stroller wrote:
> I'm also seeing that maybe alsa's default state is muted, so that the
> muted state would be correct even if the sound state is not being
> restored.

I would say the default state is muted except for one very confounding
discovery at my end, which may a big difference and may not.

After removing alsasound from /etc/runlevels/* (it was in only one level
but I can't remember now which one it was ;) I rebooted.

I use startx, so right after a reboot there is no X session running yet,
and to my astonishment I find that pulseaudio is already running:

1987 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
1991 ?        S      0:00  \_ /usr/libexec/pulse/gconf-helper

I haven't spent any time trying to discover who is starting pulseaudio
behind my back, but it at least reminds me to ask if you are also using
it on your machine.

Re: [gentoo-user] asound.state bug? Can anyone else reproduce this, please?

[Walter Dnes]

On Mon, May 07, 2012 at 09:40:41PM +0100, Stroller wrote

> I'm also seeing that maybe alsa's default state is muted, so that
> the muted state would be correct even if the sound state is not being
> restored.

  According to the Alsa-Project HDA Intel page
http://www.alsa-project.org/main/index.php/Matrix:Module-hda-intel
and probably applicable for all cards.  The quote is...

> Now adjust your soundcard's volume levels. All mixer channels are
> muted by default. You must use a native mixer program to unmute
> appropriate channels, for example alsamixer from the alsa-utils
> package. Note that some usb-audio devices do not have internal mixer
> controls. Run:
> 
>        alsamixer

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] asound.state bug? Can anyone else reproduce this, please?

[Stroller]

On 8 May 2012, at 00:53, walt wrote:
> … 
> After removing alsasound from /etc/runlevels/* (it was in only one level
> but I can't remember now which one it was ;) I rebooted.
> 
> I use startx, so right after a reboot there is no X session running yet,
> and to my astonishment I find that pulseaudio is already running:
> 
> 1987 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
> 1991 ?        S      0:00  \_ /usr/libexec/pulse/gconf-helper
> 
> I haven't spent any time trying to discover who is starting pulseaudio
> behind my back, but it at least reminds me to ask if you are also using
> it on your machine.

Ah! My apologies! 

I don't have Pulse installed on this system - I don't object to it, but it's a MythTV box, running a single app at a time, so I don't need it.

So I'm only interested in the experiences of people running only ALSA (no Pulse).

Stroller.

Re: [gentoo-user] asound.state bug? Can anyone else reproduce this, please?

[Stroller]

On 8 May 2012, at 01:35, Walter Dnes wrote:

> On Mon, May 07, 2012 at 09:40:41PM +0100, Stroller wrote
> 
>> I'm also seeing that maybe alsa's default state is muted, so that
>> the muted state would be correct even if the sound state is not being
>> restored.
> 
>  According to the Alsa-Project HDA Intel page
> http://www.alsa-project.org/main/index.php/Matrix:Module-hda-intel
> and probably applicable for all cards.  The quote is...
> 
>> Now adjust your soundcard's volume levels. All mixer channels are
>> muted by default. You must use a native mixer program to unmute
>> appropriate channels, for example alsamixer from the alsa-utils
>> package.


Right, but you snipped the important part of my quoted text:

    That's fine - restore the previous backup of sound from when audio was
    playing (`cp ~/asound.state.bu /var/lib/alsa/asound.state`) and reboot
    the system. Now the unmuted state is restored and you can listen to
    your music without starting /etc/init.d/alsasound.

Alternatively, you can ensure that the alsa startup script is stopped and disabled (`/etc/init.d/alsasound stop && rc-update del alsasound default`), manually ensure the sound is unmuted (play music), run `/etc/init.d/alsasound save` and reboot the system - the *unmuted* state is restored, even though /etc/init.d/alsasound has never been started.

So the default muting is overridden, even though this has not been requested.

This appears to contradict the option in /etc/conf.d/alsasound - RESTORE_ON_START.
We can set RESTORE_ON_START="no" and yet the setting is overridden - the sound (unmuting) *is* restored on start!

This is obviously easiest to see and demonstrate using muting, but volume levels and so on are restored, too.

I kinda feel silly making a distinction about this, because "of course" a muted soundcard is useless, and of course I want sound to be restored. But I've been trying to figure my way through how ALSA works, and it seems to be via the /etc/init.d/alsasound script, and yet I find that script is just being ignored and that the last state is restored, irrespective of that script's directives. And I guess that bugs me.

I mean, the statement "of course a muted soundcard is useless" begs the question of why ALSA ships like that in the first place (but the ALSA mailing list remains silent in response to my previous question, so let's not go there). But if it makes sense for ALSA to ship with channels muted by default, surely it makes sense for the distro not to override that without the user specifying otherwise.

I hope this makes sense. I'm not used to doing desktoppy stuff on Linux, and I do kinda feel like I'm walking in bizarro-land with this one.

Stroller.