Gene Heskett wrote:

> On Friday 05 August 2016 08:35:52 deloptes wrote:
> 
>> Gene Heskett wrote:
>> > So it is. Owned by root but world rw. Then why, if root can access
>> > it during the init phase, is it not active for me until I do an
>> > alsactl restore ? �Something in starting the x stuff as the usr
>> > after the login, is killing the sound UNTIL the user does a restore.
>> > And its a right PIMA. Just for S & G, I just added an aplay command
>> > to be executed by me, immediately after a line in rc.local that does
>> > a theoretical restore, as me to play the front-center channel id
>> > file. �I'll see if that plays when I next reboot. Which is not
>> > eminent ATM.
>>
>> In my opinion the problem is somewhere else. This file is not meant to
>> be used by user. It is used when alsa framework is initialized. When
>> you do restore you actually load the settings from this file.
>> The question is why it is not restoring on boot. You should inspect
>> the scripts used to start/initialize alsa.
>> I can't look further ATM. I would actually trace the log files, but
>> the approach with playing something is also valid, only it will not
>> help understand why if not working.
>>
>> BTW I don't have anything in rc.local. I have (jessie)
>> find /etc/rc* | grep alsa
>> /etc/rc0.d/K01alsa-utils
>> /etc/rc6.d/K01alsa-utils
>> /etc/rcS.d/S21alsa-utils
>>
>> regards
>>
> Looking at S21alsa-utils, it seems to me that I should see a log msg or
> 30 from it.  I am not, but its appears to mute the system at one point
> in the script. WTH is that for?  What I see in the last dmesg all comes
> from snd_intel, and says that msi has been disabled, whatever the heck
> that means. I'm clueless about that.
> 
> Thanks.
> 
> Cheers, Gene Heskett

Hi Gene,

and what happens if you do a /etc/init.d/alsa-utils restart instead of
calling directly alsactl?
this is just an idea for your next reboot.

In fact it is worth reading 
/usr/share/doc/alsa-utils/README.Debian

There are some very good ideas where your problem might be.

You could also remove ">/dev/null" from the script and see if alsactl gives
something back

        if MSG="$(alsactl -E HOME="$ALSACTLHOME" restore $CARD 2>&1
>/dev/null)" && [ ! "$MSG" ] ; then
                return 0
        else
                # Retry with the "force" option.  This restores more levels
                # but it results in much longer error messages.
                alsactl -F restore $CARD >/dev/null 2>&1
                log_action_cont_msg "warning: 'alsactl -E
HOME="$ALSACTLHOME" restore${CARD:+ $CARD}' failed with error
message '$MSG'"
                return 1
        fi

and further down there is a function mute_and_zero_levels, but is commented
out.
Check on your side somewhere there.

        store_levels "$TARGET_CARD" || EXITSTATUS=1
        #mute_and_zero_levels "$TARGET_CARD" || EXITSTATUS=1


BTW MSI stands for Message Signaled Interrupt (there is a driver handling
this)
https://www.kernel.org/doc/Documentation/PCI/MSI-HOWTO.txt

I hope this helps