I've had some sound problems in MX-15 with VLC and Trinity. The issue is solved... sort of. This is a link to the discussion: http://forum.mepiscommunity.org/viewtopic.php?f=100&t=40197 The short version is: After I installed KDE Plasma Desktop, the problems cleared up. Recently, they started again. If I log out of TDE, log into Plasma Desktop, log out of Plasma, then back into TDE, I have sound again in VLC.

On 08/04/2016 08:56 AM, Gene Heskett wrote: > On Thursday 04 August 2016 02:06:27 Joe wrote: >> I've had some sound problems in MX-15 with VLC and Trinity. The >> issue is solved... sort of. >> >> This is a link to the discussion: >> >> http://forum.mepiscommunity.org/viewtopic.php?f=100&t=40197 >> >> The short version is: >> After I installed KDE Plasma Desktop, the problems cleared up. >> Recently, they started again. If I log out of TDE, log into Plasma >> Desktop, log out of Plasma, then back into TDE, I have sound again >> in VLC. > > Maybe this is a good time to add to the confusion. Something in the > environment as tdm is starting shuts off the sound, and it is 100% > repeatable here, running R14.0.4. And despite my best efforts at > adding the fix it command to stuff that either runs as root by init, > (rcS) or as me when I log in, sound is deader than a nail until I > find a terminal and type in the fix it: alsactl restore. > > This has existed as a bootup problem for at least a year. I hear > the big thump in the speakers as the driver is loaded way back in > the text only portion of the reboot, which I see because I am an > anacronism and always have a no-splash on the kernel's load line in > grub.conf. That thump tells me the sound should work, so what is it > in the tdm load time frame that mutes it? > > Whatever it should be found & killed. With no regrets. SSS theory. > > Thanks. > > Cheers, Gene Heskett

MX-15, whatever that is.

Gene Heskett composed on 2016-08-04 20:54 (UTC-0400): It's a somewhat confusingly named Debian and Mepis derived lightweight Linux distro directed at older computers. See: http://antix.mepis.org/index.php?title=Main_Page

Gene Heskett wrote: It is neither in user dir not in root dir. It is saved in /var/lib/alsa/asound.state

regards --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net 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

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.

Gene Heskett wrote: 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

Gene Heskett wrote: 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 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