Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: SamK on July 27, 2010, 10:09:03 AM
-
In OnBoot is alsa, alsa-oss and alsamixergui. The mixer settings are lost between boots. How to preserve them?
I am using persistent home, opt and tce on USB flash drive and not using TC backup when exiting.
-
See info alsa.tcz
-
See info alsa.tcz
Tried alsactl store without success.
Not sure if it is necessary to start from bootlocal.sh as alsa initializes OK without it - but tried it anyway. Again no success.
Is this meant to work as described when persistent storage is being used and backups are not run By TC on exit?
-
See info alsa.tcz
Tried alsactl store without success.
alsactl restore -f /path/to/stored/statefile
-
The issue seems to be that the guidance in alsa.tcz favours users not using persistent storage and therefore backing up their data at the end of each TC session. As I am using persistent storage the advice is not appropriate.
alsactl store by default creates /etc/asound.state. This is in a non-persistent location and therefore does not survive between boots.
I can see a couple of ways around this:
- Backup at TC close (which is unsuitable for my purposes)
- Save the output of alsactl store to /home/tc/.alsacfg/asound.state
From /etc/bootlocal.sh run alsactl restore -f /home/tc/.alsacfg/asound.state
If this works, perhaps it might be added to the notes in alsa.tcz
-
The issue seems to be that the guidance in alsa.tcz favours users not using persistent storage and therefore backing up their data at the end of each TC session. As I am using persistent storage the advice is not appropriate.
alsactl store by default creates /etc/asound.state. This is in a non-persistent location and therefore does not survive between boots.
Looks to me like your issue after all is more semantical than technical and generally about persistence of files in e.g. /etc rather than about alsa per se. If i understand correctly it is you NOT using any persistent storage for anything in /etc. Just for example: checking now i found i have 6 entries starting with "etc/" in my .filetool.lst - another classical one would be "etc/X11/xorg.conf" - and 1 in "usr/local/etc/"; that's where system wide configurations are stored.
I can see a couple of ways around this:
- Backup at TC close (which is unsuitable for my purposes)
- Save the output of alsactl store to /home/tc/.alsacfg/asound.state
From /etc/bootlocal.sh run alsactl restore -f /home/tc/.alsacfg/asound.state
Suggestion: you could backup your customized /etc files to ~/.local/etc/ and then write a script to link them back to /etc/ at boot time.
If this works, perhaps it might be added to the notes in alsa.tcz
I can't see why this shouldn't work and after reading the info of alsa.tcz once again I respectfully disagree with upper suggestion, as the instructions are very generally worded and IMHO giving examples of implementation for particular scenarios within an extension .info would rather lead to confusion than to clarification.
-
You decided what is in your backup! You could just an easily specify only those non-persistent areas as shown in the .info file to have persistence and backup. Alternately you could make a tiny custom my_alsa_setting.tcz extension.
-
Looks to me like your issue after all is more semantical than technical and generally about persistence of files in e.g. /etc...
We may simply have to accept differing views on this. My interpretation of persistence is the one given in the Core Concepts document which has been my reference.
Backup/Restore and Other Persistence Options:
...Tiny Core supports persistent/permanent:
Backup and Restore of personal settings, and
Persistent /home and /opt directories.
I feel this is indicating a difference between backup and persistence. Backup is used to preserve the data in volatile storage areas between boots as the file and directory structure is destroyed at the end of the session. Persistent storage is not destroyed but remains unchanged and available at the end of the session. They are different mechanisms of ensuring the continuity of data depending on whether the storage is volatile or persistent.
My understanding is that only /home and /opt can be persistent in this way unless the hybrid/local install method is used.
...
When using the home boot code, mydata.tgz is not created - personal data backups must occur in a more traditional way.
...
This reflects my situation, the bootcode is used and persistent /home is created.
If this works, perhaps it might be added to the notes in alsa.tcz
I can't see why this shouldn't work and after reading the info of alsa.tcz once again I respectfully disagree with upper suggestion, as the instructions are very generally worded and IMHO giving examples of implementation for particular scenarios within an extension .info would rather lead to confusion than to clarification.
The guidance in alsa.info will work as described for those using volatile storage alone as filetool will be used to create a backup. The advice is less suited to those implementing the guidance in Core Concepts referring to persistent storage and backups. The suggestion to amend alsa.tcz is intended to help this latter group.
It is good to have different opinions expressed; after all that is what a forum is all about. Thanks for your suggestion to use alsactl restore as it had not occurred to me. As is often the case there can be many ways to resolve a problem and your input helped.
...You could just an easily specify only those non-persistent areas as shown in the .info file to have persistence and backup. Alternately you could make a tiny custom my_alsa_setting.tcz extension.
Yet more examples of the multiple ways to resolve an issue.
-
Since info files are geared towards those new to an extension, one simple and standard example is the way to go as I agree that multiple examples often would just lead to confusion.
I remember a time when folks and even myself were seeing issues with restoring alsa settings between reboots using the /usr/local/etc/init.d/alsasound script along with a backed up /etc/asound.state file. Not sure if it was a timing issue or what, and I have not seen it happen in a long time. But I see at least on my machine now that simply using "alsatcl -f /path/to/file store" before reboot and "alsactl -f /path/to/file restore" after rebooting, it works and restores alsa settings without the use of the /usr/local/etc/init.d/alsasound script. So this may be an alternative method that can help.
The main reason for the alsasound script was to insert the proper kernel modules, which udev seems to handle now anyway, though I am sure there are cases with certain hardware the script needs to be run. But at least here, a simple use of the alsactl store and restore is all that is needed to set up alsa between sessions, so I will make a mention of it in the info file.
-
But I see at least on my machine now that simply using "alsatcl -f /path/to/file store" before reboot and "alsactl -f /path/to/file restore" after rebooting, it works and restores alsa settings without the use of the /usr/local/etc/init.d/alsasound script. So this may be an alternative method that can help.
There are plenty of scenarios where using "alsactl -f /path/to/file restore" manually can be to great benefit:
- on resource challenged PC's one might only decide to load alsa in TC when it becomes really needed (as opposed to boot time).
That of course is only if one is not too keen to be greeted by Bethooven's 5th or similar as could be default by various deskbloat environments :P - Porting same set of config files (e.g. mydata.tgz) between multiple PC's, e.g. having asound.state.Toshiba and asound.state.Thinkpad
- But most convenient for many users: Having several pre-configured mixer settings for different purposes, e.g. asound.state.VoIP, asound.state.playback and asound.state.record. "/etc/asound.state" is just a default path for convenience, but by no means compulsary.
-
hi
I would like to thank all members for their comments as I found this post by search.
however, it appears SamK did not usesudo alsactl store
as we need root powers to write to /etc.
-
Hi aus9
hi
I would like to thank all members for their comments as I found this post by search.
however, it appears SamK did not usesudo alsactl store
as we need root powers to write to /etc.
There seems to be some confusion here, perhaps I can help with a little clarification.
You are correct in observing that the use of sudo is required; behind the scenes I had also used sudo without success. This was due to the persistent storage configuration used on the machine, allied to the information in the wiki Core Concepts document.
I was trying to highlight that when following the guidance in Core Concepts (particularly persistence and storage), a user would not be able to follow the advice in alsa.tcz.info to make the alsa settings persist between reboots. Jason has subsequently added further guidance to the alsa information which can be used by those with persistent or non-persistent storage.
-
You might wanna have a look at http://forum.tinycorelinux.net/index.php?topic=6943.0 in order to determine which files in /etc (and possibly other root dirs e.g. /usr) to save/backup ;)
-
You might wanna have a look at http://forum.tinycorelinux.net/index.php?topic=6943.0 in order to determine which files in /etc (and possibly other root dirs e.g. /usr) to save/backup ;)
You point to a fine piece of work. It gets a list of files from mydata.tgz, presumably created by filetool.lst. In the terms of this thread this may have limited the value of the script.
For this particular purpose filetool.lst and mydata.tgz are not used; this also correlates with the guidance given in Core Concepts relating to the backup of persistent storage.
...
When using the home boot code, mydata.tgz is not created - personal data backups must occur in a more traditional way.
...
Also I tried to indicate in my opening post that the standard TC backup will not be used. Amongst other reasons, it is intended that ultimately the machine will join a LAN based backup system.
-
Umm, have you looked at all options in detail? ???
-
I'm not clear what you're referring to.
-
I couldn't see how any option except from -s and unlikely -a would depend on the existence of a backup.
-
I have not downloaded or run the script. My comments were solely based on the information given in posts in the thread referred to.
-
Well if you carefully read the whole thread, the option depending on backup was only added at a later stage as an extra ;)
What i had in mind that this script is ideal even for your non-default setup to determine which files to back up (in whatever way you wish to do so) ;)
-
Alsa on IBM Thinkpad , curaga and clach04 rock!
Will try to keep it brief:
After 2.8 could not get Alsa to work, just noticed wiki "Setting up sound" had changed, followed the directions, blacklisted the cs_4610 card in boot options applied the persistence instructions in the wiki and it all works beautifully.So read the wiki and use the settings the guys give hope it works for you
Thanks Guys
oldgit
-
Could you set, that in fresh installation Master vol will be on 75% by default?
The idea is that I don't have to run alsamixer every time I boot TCL. I don't want to use asound.state.
-
Hi neonix
These are the instructions from alsa.tcz.info:
----------
If you want your alsa settings to persist across reboots, use the
command "sudo alsactl store" after alsa has been set up and
add /usr/local/etc/alsa/asound.state to your backup
if alsa is loaded onboot you may need "sudo alsactl restore"
----------Similar instructions have been posted on this forum.
I doubt the extension will be customized to meet your needs
just so you don't have to follow the recommended instructions.
-
Then could you put "xterm alsamixer" to menu list? (alsa.tcz)
That I don't have to type alsamixer eveytime I boot puter.
-
Hi neonix
Then could you put "xterm alsamixer" to menu list? ...
No, but you can.
Download the attachment, then:
tce-load -wil squashfs-tools
mkdir -p pkg/usr/local/share/applications
cp alsamixer.desktop pkg/usr/local/share/applications
mksquashfs pkg alsamixer.tcz
cp alsamixer.tcz /etc/sysconfig/tcedir/optional
tce-load -i alsamixer
-
And then, could you put alsamixer.tcz (alsamixer-set.tcz) to the repo?
It will contains:
unmute Master
75% Master vol
xterm alsamixer
Automatisation can save my precious time, especially if I have many computers with TCL installed.
-
Hi neonix
I provided you with a .desktop file and instructions for
creating an extension that will add alsamixer to your
desktop menu.
If you want it to set volume and unmute, add this before
running the mksquashfs command:
mkdir -p pkg/usr/local/tce.installed
printf '#!/bin/sh\n\namixer set "Master" 23 unmute\n' > pkg/usr/local/tce.installed/alsamixer
chmod 755 pkg/usr/local/tce.installed/alsamixer
If you want this extension to set volume and unmute, alsa
must already be configured before loading this extension.
-
You can use "sleep 50" to execute instruction after alsa.tcz is loaded.
-
Hi neonix
If you are talking about adding a sleep command to the
pkg/usr/local/tce.installed/alsamixer script, no you can't.
That could block other extensions from loading and their
tce.installed scripts from running for 50 secs.
-
My goal is that every user who install fresh TCL, have working sound out of the box.
Why other distros can have this, and TCL don't have this? In TCL I have to make few procedures to have working sound in alsa, and wast time, when it could be automati zed.
-
Hi neonix
My goal is that every user who install fresh TCL, have working sound out of the box. ...
Really? Your goal? Based on you actions, you don't seem very committed to "your goal".
You ask about adding alsamixer to your menu. I provided you with
a .desktop file and instructions, but you couldn't be bothered to
use them.
Run these commands:
printf '#!/bin/sh\n\namixer set "Master" 23 unmute\n' > UnMute
chmod 755 UnMuteYou now have an executable script called UnMute that will set
the master volume at 74% and make sure it's not muted.
Place the script in your systems path (~/local/bin/, /usr/local/bin/, /usr/bin/,
whatever) and decide where to call it from. Or copy the contents and add
them to one of your startup scripts. Or create an extension.
Just remember, alsa has to be configured before you can set the volume.
-
If I create optional extension alsamixer-set.tcz with
asound.state
and "xterm alsamixer" in menu list. Would you put it into repo?
-
Hi neonix
I think asound.state might include hardware specific
information. If that is the case, then I would say no.
-
And if alsa-set.tcz or alsamixer-set.tcz will contains this?
pause 5
amixer set Master unmute
amixer set PCM unmute
amixer set Headphone unmute
amixer set Master 75%
amixer set PCM 75%
amixer set Headphone 75%
[Desktop Entry]
Name=alsamixer
Exec=aterm -e alsamixer
Icon=
Terminal=false
X-FullPathIcon=
Type=Application
;OnlyShowIn=Old;
Categories=Utility;
-
Hi neonix
And if alsa-set.tcz or alsamixer-set.tcz will contains this?
pause 5
amixer set Master unmute
amixer set PCM unmute
amixer set Headphone unmute
amixer set Master 75%
amixer set PCM 75%
amixer set Headphone 75% ...
I'm guessing you meant sleep 5 for the first line.
If that is supposed to be a startup script that goes in
/usr/local/tce.installed , then no.
When Tinycore boots, it first loads all of the extensions
in onboot.lst. it then runs all of the startup scripts for
those extensions. Any extensions that were loaded after
yours, would now have their startup scripts blocked from
running while yours sits there and sleeps.
... [Desktop Entry]
Name=alsamixer
Exec=aterm -e alsamixer
Icon=
Terminal=false
X-FullPathIcon=
Type=Application
;OnlyShowIn=Old;
Categories=Utility;
That one is fine. As shown, it will only provide an entry
for the desktop menu, but no icon for the wbar.
If you want an icon, you need to provide one and add
something like this:
Icon=alsamixer
X-FullPathIcon=/usr/local/share/pixmaps/alsamixer.png
-
SliTaz 2.0 has something like this.
#!/bin/sh
# Set and store default mixer volumes for SliTaz. Used at boot time
# if a sound card has been detected automatically and can be used
# directly.
#
echo "Setting default mixer volumes..."
amixer -s -q <<EOF
set Master 75% unmute
set Master -12dB
set 'Master Mono' 75% unmute
set 'Master Mono' -12dB
set Front 75% unmute
set Front -12dB
set PCM 90% unmute
set PCM 0dB
mixer Synth 90% unmute
mixer Synth 0dB
mixer CD 90% unmute
mixer CD 0dB
# mute mic
set Mic 0% mute
# ESS 1969 chipset has 2 PCM channels
set PCM,1 90% unmute
set PCM,1 0dB
# Trident/YMFPCI/emu10k1
set Wave 100% unmute
set Music 100% unmute
set AC97 100% unmute
# CS4237B chipset:
set 'Master Digital' 75% unmute
# Envy24 chips with analog outs
set DAC 90% unmute
set DAC -12dB
set DAC,0 90% unmute
set DAC,0 -12dB
set DAC,1 90% unmute
set DAC,1 -12dB
# some notebooks use headphone instead of master
set Headphone 75% unmute
set Headphone -12dB
set Playback 100% unmute
# turn off digital switches
set "SB Live Analog/Digital Output Jack" off
set "Audigy Analog/Digital Output Jack" off
EOF
# Store config
alsactl store
If alsa.tcz is executed/mounted before alsa-set.tcz then this script will works theoretically (in TCL)?
Other solution is to execute this script from (jwm) menulist manually.
The question is, can I put this solution in to the repo?
-
Hi neonix
... Other solution is to execute this script from (jwm) menulist manually. ...
That makes a lot more sense than having something like
this try to run automatically.
... The question is, can I put this solution in to the repo?
Have you tested it? Does it work?
-
Yes, it works.
Now I have alsamixer wbar icon, menulist for mixer set, and menulist entry for alsamixer. If I send it be email, would you put it in alsa.tcz or alsamixer-set.tcz?
-
Hi neonix
menulist for mixer set, ...
Change mixer set to mixer reset to make it a bit more
obvious it's going to reset to some default values, and
not offer the user to select some settings.
... If I send it be email, would you put it in alsa.tcz or alsamixer-set.tcz?
Create the following:
alsamixer-set.tcz
alsamixer-set.tcz.dep
alsamixer-set.tcz.list
alsamixer-set.tcz.info
alsamixer-set.tcz.md5.txt
Then tar them up:
tar -cf alsamixer-set.tar *.tcz*
gzip -9 alsamixer-set.tar
Run bcrypt:
bcrypt alsamixer-set.tar.gz
Encryption key: tinycore
And send it to tcesubmit @ gmail … com
More info on extension creation here:
https://wiki.tinycorelinux.net/doku.php?id=wiki:creating_extensions#creating_a_tcz