Hide Forgot
Description of problem: I am unable to save the envy24ctl settings or alsactl with M-Audio 2496 card. This is an important app for users of this card that are using it for "pro" audio stuff. For example I want to have the mixers set in a certain position by default. Instead I have to manually adjust all the settings after each reboot. Version-Release number of selected component (if applicable): 1.0.22-1 How reproducible: Always Steps to Reproduce: 1. change various mixer or other settings using envy24ctl 2. use sudo alsactl -d store M2496 to store settings to /etc/asound.state file. 3. use sudo alsactl -d restore M2496 to restore settings Actual results: Step 3 will work under current session, but does not restore settings following a reboot. need to reboot and find that restore does not work. This is a problem because volume settings are at 0 by default. Expected results: Expect the settings to be restored. Additional info: This is procedure I used to figure this out and fix.. 1008 sudo alsactl -d store M2496 [stores settings] 1009 sudo alsactl -d restore M2496 [should restore, but only gives error after reboot] 1020 sudo nano /etc/asound.state [can fix this by editing out control.45 section which was causes problem with restore] [found to be causing problem by using diff on different stored versions] also see similar.. http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025694.html
does it work if you specify -I ? alsactl -help -I,--no-init-fallback don't initialize even if restore fails
post the /etc/asound.state use -d to debug Available global options: -d,--debug debug mode
Created attachment 427252 [details] alcactl -d output Output from: alsactl -d restore M1010LT 2> alsactM1010LT.txt
In the last week I've changed from the M2496 soundcard to a very similar M1010LT card. This card has the same issue. I've also noticed that the kernel may be playing a part here also. I set up (using alsactl) the soundcard on the stock Fedora 12 kernel (2.6.32) and then tried to use it on the CCRMA realtime kernel (2.6.31). On realtime, I cannot restore any settings, but on the regular kernel it appears I can. Please see the attachment I just posted.
To debug the restore function of alsactl, you should see the debug message (result code, maxnumid, doit and the device ) similar to the following alsactl -d restore -f abc.txt ./alsactl: set_controls:1420: device='hw:0', doit=0 ./alsactl: set_controls:1432: card-info-id: 'au8830' ./alsactl: set_controls:1458: maxnumid=54 ./alsactl: set_controls:1476: result code: 0 ./alsactl: set_controls:1420: device='hw:0', doit=1 ./alsactl: set_controls:1432: card-info-id: 'au8830' ./alsactl: set_controls:1458: maxnumid=54 ./alsactl: set_controls:1476: result code: 0 ./alsactl: set_controls:1420: device='hw:1', doit=0 ./alsactl: set_controls:1432: card-info-id: 'Intel' ./alsactl: set_controls:1458: maxnumid=49 ./alsactl: set_controls:1476: result code: 0 ./alsactl: set_controls:1420: device='hw:1', doit=1 ./alsactl: set_controls:1432: card-info-id: 'Intel' ./alsactl: set_controls:1458: maxnumid=49 ./alsactl: set_controls:1476: result code: 0
Created attachment 427543 [details] the asound.state file you requested is attached
Concerning Comment #5, I attached the debug yesterday. However, I'm trying this again today after another reboot into the rt kernel and it seems to be working fine now. Strange
Note that http://mudita24.googlecode.com (a fork of envy24control(1)) has a working profiles feature that will do exactly what you need. I described this functionality in a recent LAU post http://linuxaudio.org/mailarchive/lau/2010/8/8/172627 On Sat, Aug 7, 2010 at 6:10 PM, Geoff Beasley <laughingboyrecords.com> wrote: > Niels, great that you and Tim have fixed this app ;) One thing, can you > explain what those 'profiles' are for and how to use them? Envy24control uses the same mechanism as your system does (see /etc/asound.state and amixer(1)) to save the state of your ALSA devices between boots. The difference is this mechanism puts the file under your control at ~/.envy24control/profiles.conf and allows you to set eight different profiles: allowing you to save or restore up to eight different "asound.state"-like configurations per card. The different profiles are most useful for storing routings set in "Patchbay/Router" panel, as well as "Hardware Settings" panel clock rate, or external SPDIF/wordclock sync. On cards with switchable spdif/optical ins (Terratec/Terrasoniq), you can persist this extra level of "routing" -- which is useful for "matrix routing" between two digitally-interconnected and sync'd computers. ( I use profiles named: 44dmix-to-1&2&spdif, 48dmix-to-1&2&spdif, spdmix-to-1&2&spdif, 44all-outs-pcm, 48all-outs-pcm, spdif-all-outs-pcm, 96dmix-to-1&2&spdif and 96all-outs-pcm. ). When you have a combination of settings in envy24control that you want to return to, just go to the "Profiles" panel, enter the name of the profile into the first free text field (initially these will be numbered "1" through "8"). After entering a descriptive name, click "Save active profile." To restore a given profile, just click on the "button" area surrounding the text field, or even click within the text field. You'll notice the selected profile "button" indicates activation via coloration. After changing profiles, go to, for example, Patchbay/Router or "Hardware Settings" panels,and note that the previously saved state was restored. Note that significant amounts of setting data gets saved in these files: > ll ~/.envy24control/ -rw-r--r-- 1 npm npm 115253 2010-08-07 23:10 profiles.conf For comparison: > ll /etc/asound.state -rw-r--r--. 1 root root 128079 2010-08-07 18:15 /etc/asound.state (That's for a system with two envy24-based cards installed, thus size is large, causing "save" to produce a brief but noticeable pause in the metering on a slower system or "ondemand" throttled system). Niels http://nielsmayer.com
(In reply to comment #7) > Concerning Comment #5, I attached the debug yesterday. > > However, I'm trying this again today after another reboot into the rt kernel > and it seems to be working fine now. Strange it is because The interface of The "Multi Track Peak" control has been changed from IFACE_MIXER TO IFACE_PCM so you need to upgrade envy24control http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=2bdf66331c3ff8d564efe7a054f1099133d520cd does mudita24 backward compatible with ice1712 with earlier version alsa-driver before the change
(In reply to comment #9) > does mudita24 backward compatible with ice1712 with earlier version alsa-driver > before the change Mudita24 was based on trunk version of envy24control, and thus, incorporates the change you mention regarding Multi Track Peak that should be present in updated versions of alsa-tools. I'd assume this fix is also included recent updates of Fedora 12, as well as the stock Fedora13 release. http://nielsmayer.com/envy24control/mudita24-envy24control-0.6-to-1.0.3.patch is the patch to envy24control's trunk (recent), incorporating current 1.03 changes. http://lalists.stanford.edu/lad/2010/08/0059.html is a useful additional patch to 1.03 that will eventually be part of 1.04...
backward compatible mean can mudita24 work on Fedora 10 or earlier version which "Multi Track Peak" control is still using IFACE_MIXER
I consider this fixed for me. I have not experienced this problem for awhile now. Switching between current FC13 stock kernel (2.6.34.6-47.fc13.i686) or FC13 CCRMA realtime kernel (2.6.33) is works. I'm also using mudita24 with the latest patch (1.03+) and it works fine and also lets me use the presets. Geoff
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping