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
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: trinity-users-help@xxxxxxxxxxxxxxxxxxxxxxxxxx
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
