Tiny Core Extensions > TCE Q&A Forum
Retaining alsamixer settings between boots
tinypoodle:
--- Quote from: SamK on July 27, 2010, 01:02:07 PM ---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.
--- End quote ---
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.
--- Quote ---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
--- End quote ---
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.
--- Quote ---If this works, perhaps it might be added to the notes in alsa.tcz
--- End quote ---
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.
roberts:
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.
SamK:
--- Quote from: tinypoodle ---Looks to me like your issue after all is more semantical than technical and generally about persistence of files in e.g. /etc...
--- End quote ---
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.
--- Quote from: Core Concepts ---Backup/Restore and Other Persistence Options:
...Tiny Core supports persistent/permanent:
Backup and Restore of personal settings, and
Persistent /home and /opt directories.
--- End quote ---
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.
--- Quote from: Core Concepts ---...
When using the home boot code, mydata.tgz is not created - personal data backups must occur in a more traditional way.
...
--- End quote ---
This reflects my situation, the bootcode is used and persistent /home is created.
--- Quote from: tinypoodle ---
--- Quote ---If this works, perhaps it might be added to the notes in alsa.tcz
--- End quote ---
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.
--- End quote ---
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.
--- Quote from: roberts ---...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.
--- End quote ---
Yet more examples of the multiple ways to resolve an issue.
Jason W:
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.
tinypoodle:
--- Quote from: Jason W on July 28, 2010, 06:10:29 AM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version