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 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
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
On Thursday 04 August 2016 16:34:57 Joe wrote:
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
Joe, please don't put your reply below anybody's sig disconnecter. You did, and that means I have to copy & paste from your message to this one. The sig disconnect is a newline,dash,dash,space,newline and no email agent I know of fails to honor it unless its some winders thing.
Now I'll copy and paste:
Gene,
I'm cross-posting your reply to my thread in the MX-15 Modified forum so they will know that this is not exclusively a Trinity on MX-15 problem.
Thanks, -Joe
I never for a millsecond thought it was an MX-15 problem. I've had an aftermarket card it did it to, and it does it to the motherboard audio system on this now elderly Asus motherboard. Post away, as I see no reason to launch a machine code trace on your MX-15, whatever that is.
As for trinity, ISTR I also had problems with kde doing the same thing before I jerked it out by its hair and put trinity in. And I have lost a lot less blood annually with trinity than I have with kde for the last 6 or 7 years. I like stability.
Cheers, Gene Heskett
Gene Heskett composed on 2016-08-04 20:54 (UTC-0400):
MX-15, whatever that is.
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
On Thursday 04 August 2016 21:07:51 Felix Miata wrote:
Gene Heskett composed on 2016-08-04 20:54 (UTC-0400):
MX-15, whatever that is.
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
Humm, downright purty. But it looks like x is actually well supported unless thats a wayland preview.
Cheers, Gene Heskett
Gene Heskett wrote:
and type in the fix it: alsactl restore.
perhaps try alsactl store ? It helps.
No issue here with the sound and never had, though this problem was visible from time to time during the years on different machines after upgrades, migration to new hardware etc etc. Storing the settings solves it. This should be called on shutdown/reboot as well same as restore on boot by the init script AFAIR. I am not sure if TDE saves the state. My impression is it reads the state from alsa.
regards
On Thursday 04 August 2016 20:58:50 deloptes wrote:
Gene Heskett wrote:
and type in the fix it: alsactl restore.
perhaps try alsactl store ? It helps.
Only if you have called up the alsoctl.gui and made it functional. No use storing defective settings into your home dir.
No issue here with the sound and never had, though this problem was visible from time to time during the years on different machines after upgrades, migration to new hardware etc etc. Storing the settings solves it. This should be called on shutdown/reboot as well same as restore on boot by the init script AFAIR. I am not sure if TDE saves the state. My impression is it reads the state from alsa.
In which case it is reading a defective file in /root since the shutdowen and init stuff runs as root, whereas if I run the restore from a terminal, as me, then it reads a good file from my home dir, one that I previously saved after calling up the gui as me and making it work.
regards
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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
Cheers, Gene Heskett
Gene Heskett wrote:
On Thursday 04 August 2016 20:58:50 deloptes wrote:
Gene Heskett wrote:
and type in the fix it: alsactl restore.
perhaps try alsactl store ? It helps.
Only if you have called up the alsoctl.gui and made it functional. No use storing defective settings into your home dir.
No issue here with the sound and never had, though this problem was visible from time to time during the years on different machines after upgrades, migration to new hardware etc etc. Storing the settings solves it. This should be called on shutdown/reboot as well same as restore on boot by the init script AFAIR. I am not sure if TDE saves the state. My impression is it reads the state from alsa.
In which case it is reading a defective file in /root since the shutdowen and init stuff runs as root, whereas if I run the restore from a terminal, as me, then it reads a good file from my home dir, one that I previously saved after calling up the gui as me and making it work.
It is neither in user dir not in root dir. It is saved in /var/lib/alsa/asound.state
regards
On Friday 05 August 2016 05:18:10 deloptes wrote:
Gene Heskett wrote:
On Thursday 04 August 2016 20:58:50 deloptes wrote:
Gene Heskett wrote:
and type in the fix it: alsactl restore.
perhaps try alsactl store ? It helps.
Only if you have called up the alsoctl.gui and made it functional. No use storing defective settings into your home dir.
No issue here with the sound and never had, though this problem was visible from time to time during the years on different machines after upgrades, migration to new hardware etc etc. Storing the settings solves it. This should be called on shutdown/reboot as well same as restore on boot by the init script AFAIR. I am not sure if TDE saves the state. My impression is it reads the state from alsa.
In which case it is reading a defective file in /root since the shutdowen and init stuff runs as root, whereas if I run the restore from a terminal, as me, then it reads a good file from my home dir, one that I previously saved after calling up the gui as me and making it work.
It is neither in user dir not in root dir. It is saved in /var/lib/alsa/asound.state
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.
regards
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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
Cheers, Gene Heskett
Am Freitag, 5. August 2016 schrieb Gene Heskett:
On Friday 05 August 2016 05:18:10 deloptes wrote:
Gene Heskett wrote:
On Thursday 04 August 2016 20:58:50 deloptes wrote:
Gene Heskett wrote:
and type in the fix it: alsactl restore.
perhaps try alsactl store ? It helps.
Only if you have called up the alsoctl.gui and made it functional. No use storing defective settings into your home dir.
No issue here with the sound and never had, though this problem was visible from time to time during the years on different machines after upgrades, migration to new hardware etc etc. Storing the settings solves it. This should be called on shutdown/reboot as well same as restore on boot by the init script AFAIR. I am not sure if TDE saves the state. My impression is it reads the state from alsa.
In which case it is reading a defective file in /root since the shutdowen and init stuff runs as root, whereas if I run the restore from a terminal, as me, then it reads a good file from my home dir, one that I previously saved after calling up the gui as me and making it work.
It is neither in user dir not in root dir. It is saved in /var/lib/alsa/asound.state
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.
regards
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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
Cheers, Gene Heskett
Hi Gene!
I have none of these issuse, but I have banned systemd from all linuxcnc-boxes.
Nik
On Friday 05 August 2016 07:12:40 Dr. Nikolaus Klepp wrote:
[snip]
Hi Gene!
I have none of these issuse, but I have banned systemd from all linuxcnc-boxes.
Nik
Hi Nik;
I'm still on wheezy for all 4, going on 5 machines. Is there some hidden systemd stuff I haven't stumbled over yet?
Yeah, I see a tree of stuff in /etc/systemd/system, but none of that looks like it would effect alsa. But there is dbus stuff, and I use that facility heavily on this machine.
Cheers, Gene Heskett
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
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
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
On Friday 05 August 2016 16:33:40 deloptes wrote:
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.
It still works after the restart.
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 morelevels # 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=1BTW 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
It might well, when I am awake. Short night last night. Msg marked for further reading. Thank you.
Cheers, Gene Heskett
-
deloptes -
Dr. Nikolaus Klepp -
Felix Miata -
Gene Heskett -
Joe